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INTRODUCTION 

The purpose of this project is to determine the feasibility of implementing various technologies 
in transit systems within Montana to assist in the collection and accounting of passenger fares. 
The research included the following objectives: 

1 . Review the state of the practice in the transit industry of automated cost recovery 
systems, and their applicability in Montana. 

2. Review current technologies in Montana, such as Montana Access, to see if these 
systems/technologies could be expanded to include automated cost recovery in 
Montana's transit systems. 

3. Complete a requirements analysis that reviews the business practice of transit systems to 
determine what issues might affect implementing an automated cost recovery system. 

4. Review potential technologies/systems to determine if there would be any issues relating 
to the Americans with Disabilities Act (ADA). 

5. Develop a benefit/cost ratio to determine if implementing an automated cost recovery 
system in Montana is feasible. 

6. Provide an implementation document that will highlight any key barriers, hurdles or 
issues that would need to be addressed, should a decision be made to implement an 
automated cost recovery system. 

Public and specialized transportation (transit) providers in Montana and other states use a variety 
of methods for collecting fares from riders, invoicing agencies for rides, and collecting ridership 
data. In urban areas, electronic passes may be used, while in rural areas a simple "paper and 
pencil" method may be used. While simpler methods may require less infrastructure (computers, 
communications equipment, etc.), they may actually be less efficient, requiring more time for 
personnel to consolidate data, invoice for services, and complete other data management tasks. 

Many larger urbanized transit systems are using automated (electronic) methods of collecting 
fares, tracking ridership data, and invoicing agencies/organizations for rides. Methods may 
include magnetic strip cards, smart cards, or stored value cards. In addition, some states have 
implemented statewide software solutions to automate as much data collection, analysis and 
reporting as possible. The Client Ridership Referral and Financial Tracking (CRRAFT) system 
used in New Mexico is one example of this type of software. In addition to customized software 
packages, commercial off-the-shelf (COTS) systems are available. 

In an earlier project, the Western Transportation Institute (WTI) worked with MET Transit of 
Billings to identify the benefits of Computer- Aided Scheduling and Dispatching Software. These 
software packages not only assist with the scheduling of demand-responsive systems, but can 
also help with data analysis, invoicing, and other planning and management requirements. These 
software systems can be integrated with fixed-route transit systems to provide an integrated 
solution for a transit system. Based on the first WTI report, MET Transit put out a Request for 
Proposals, and selected RouteMatch Software as the new provider of software for MET Special 
Transit (MST). WTI was subsequently asked to complete an analysis of MST before and after 
the implementation of the RouteMatch software. This project served as foundational research for 
conducting a benefit/cost analysis of an advanced public transportation system. 
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The following sections describe the information gathered with regard to the six objectives noted 
above and are presented so that the Montana Department of Transportation (and potential 
partnering agencies) can determine whether or not to move forward with the implementation of 
automated cost technologies. In addition, the report includes the following reference materials in 
the Appendix: the survey distributed to Montana transit providers (Appendix A) and a summary 
of the results (Appendix B); background material on mobile data computer systems (Appendix 
C), and a copy WTI's report on the analysis of MET Special Transit (Appendix D). 
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AUTOMATED COST RECOVERY & FARE PAYMENT TECHNOLOGIES 

The United States transit industry has a long and, at times, varied record with automated fare- 
collection systems. Every day, hundreds of thousands of U.S. transit customers use various 
passes and cards to pay for their transit trips. Across the world in Europe, Asia, the Americas and 
Africa, millions of customers are able to access and benefit from public transportation every day. 
Increasingly, payment devices like credit cards, debit cards, cellular telephones and other tags 
and devices are being used that provide inexpensive, secure and accurate transactions for 
customers and operators alike. Through the use of electronic fare payments, interoperability is 
fast becoming the norm, enhancing the ability of different agencies to coordinate and share 
information so that passengers can travel in a seamless fashion. 

There are numerous rail-, bus-, transit- and paratransit-based examples around the world of 
interoperable systems. These systems integrate payment methods and devices that link separate 
operators, allowing for revenue sharing among providers and giving customers seamless, single 
payment solutions for their transportation options. In the United States, notable examples of 
large automated fare systems include the San Francisco Bay area, Washington D.C., Boston and 
Chicago. Other systems in development or deployment that deserve study include those in 
Houston, the Puget Sound area, Los Angeles and Salt Lake City. This list is not exhaustive but 
will serve to provide examples of important opportunities and lessons for the state of Montana. 

As will be noted later, the electronic payment industry and the transit industry are both changing 
rapidly. New payment approaches from the banking and card payment industries are converging 
with new needs from the transit industry to "do more with less," improve measurable efficiency 
and create new opportunities for both. This section will review existing and emerging 
technologies for electronic and automated payment systems, review some existing applications 
of those technologies in the transit industry, examine similar technology and business 
management approaches in other industries, and look at the role of the private payment industry 
in the development of tools and applications. 

Current Transit Technologies 

Traditionally, a majority of transit operations have relied on cash- and pass-based systems to 
collect revenue from their passengers. Fareboxes currently in use range from very simple "drop" 
fareboxes that merely collect and securely hold payments, to more sophisticated "registering" 
fareboxes that count the fares, validate currency and passes, and record transaction information 
(Figure 1). 
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Source: (Diamond Manufacturing 2008; GFI GENFARE 2008) 

Figure 1: Basic and Advanced Fareboxes 

There are two main types of fare media: smartcards and magnetic stripe cards (Figure 2). Both 
allow easy passenger identification and payment of fare without using cash. Magnetic stripe 
cards typically only allow the fare (value) to be deducted from the card, while smartcards deduct 
fares from a cash value stored on an imbedded microchip. Smartcards typically also allow value 
to be added to the card, while this is not typical with magnetic stripe cards, although this is 
changing. 



CharOeTiGket 
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Source: (Hodges 2007) 

Figure 2: Magnetic Stripe and Smart Cards 

Many regional systems within the United States are using smartcards, but most of these systems 
are large metropolitan systems. There are, however, many large and small systems using 
magnetic stripe cards. There are two basic types of magnetic stripe media: read-only swipe cards 
and read-write, stored-value cards. The read only technology is similar to that used for credit or 
debit cards, and allows the automatic determination of the validity of an unlimited-ride pass. 
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Current Technologies 



There are also machine-readable paper tickets that are printed with specific ink that makes 
counterfeiting very difficult. These tickets offer a possible replacement for paper transfers or 
single-ride fare tickets. The read-write technology, used with a ticket processing unit (TPU) or 
bus ticket validator (BTV), can accommodate stored-value and other automated payment 
options. The use of magnetic farecards on bus systems is a more recent development, but as of 
late 2002, read-write technology had been implemented by more than 30 U.S. bus operators. 

There are many multi-operator systems utilizing smart cards. Some examples include: the New 
York City Transit Metro-Card system; the state of Connecticut, with services in Hartford, New 
Haven and Stamford; and southern California, where five operators accept the Metrocard. 

Farecards have proven very popular among customers. The greatest benefit magnetic stripe cards 
have had for customers is a wider variety of convenient payment methods. Many magnetic stripe 
card programs offer "rolling passes," which free the customer from being constrained to a 
particular calendar timeframe. Unlimited, 30-, or 31-day passes are easily purchased, and do not 
require a rider to have to "pay with cash" each time they board a vehicle. Magnetic stripe cards 
can reduce the cost of travel for many riders through the availability of one-day passes or stored- 
value cards (Figure 3). 
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Source: (Kack 2007) 

Figure 3: Fare- and Time-Based Pass Options 

The cost of these collection approaches varies greatly and depends primarily on the level of 
complexity that the transit operator is willing to pay for. Transit operators tend to adopt one type 
of equipment and then stay with the specific manufacturer for decades. This can lead to 
significant technical, physical and institutional barriers when considering whether to change or 
upgrade existing revenue collection systems. Technical challenges can include system hardware 
and software changes, staff training and other agency impacts. Physical challenges can range 
from installation of new equipment on vehicles to reconfiguring cash counting rooms to adapt to 
new or different equipment. Institutional barriers can include cost, perceived benefits, actual 
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benefits, the existence of long-standing vendor relationships, and a general reluctance to change 
equipment and procedures. 

Many older, card-based fare collection systems are based on magnetic stripe cards that are 
physically and functionally similar to well known credit cards and products such as gift cards. 
The systems can be either account-based, which means that there is a background account 
balance that the card draws against, or they can be card-based, where the cash value is stored on 
the card in what can be referred to as an "electronic purse." There are numerous examples of 
each approach. The business, privacy and security standards of the transit operator play a 
significant role in the decision whether to employ the account-based or card-based approach. It is 
important to note that the same type of card can be used in either approach; it varies by the 
amount of information with which the card is encoded when it is issued. 

The payment card industry and the security card industry have adopted full standards that govern 
the structure, type and security of the card data, while the transit industry has yet to adopt either 
those or their own standards. The Payment Card Industry (PCI) standards have been agreed upon 
and widely adopted by all major financial institutions in the United States. The card-issuing 
companies require vendors to meet those standards or risk fines and/or transaction refusals. As a 
result of not having widely accepted standards, fare vendors in the transit industry have tended 
toward proprietary standards and approaches that are specific to the vendor and not easily 
transferable to other vendors or customer needs. 

Closed or proprietary systems tend to be linked via hardware or software as integrated systems 
and are often sold as complete packages to operators. There are advantages and disadvantages 
associated with either approach that should be a large part of any procurement consideration. The 
typical transit or other small dollar purchase (less than $50) is exemplified by the current 
marketing of "tap and go" or "touch and go" (proximity card) purchases at convenience stores 
and fast food restaurants (Figure 4). 
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Source: (MasterCard 2008) 

Figure 4: Proximity Card 

Other contactless technologies include building access cards, student identification cards, 
business identification cards and others. All of these cards can be purchased and encoded to meet 
current payment industry standards and can be read by commonly available, off-the-shelf card 
readers made by a variety of manufacturers. Most of the existing card types can be read by off- 
the-shelf multi-function card readers that meet PCI standards for data transmission and security. 
Adapting these existing card types to proprietary transit card systems is possible, but relies on the 
transit operator and vendor to coordinate with the third party to modify their systems to allow the 
use of the cards in their payment network. 

"Smart Card" Or Radio Frequency Identification (RFID) -Based Applications 

Travelers are familiar with numerous successful electronic card-based systems throughout the 
world. Increasingly, transit customers and travelers are seeing these systems spread across the 
country as systems become slightly less expensive to implement and the need to improve 
revenue management, collect accurate data and build customer relationships increases for transit 
operators. Hundreds of systems across the world employ electronic cards to collect and manage 
millions of transactions every day. Famous and heavily used card systems include the "Oyster" 
card in London, the "Octopus" card in Hong Kong, the "Suica" card in Tokyo and multi-use 
cards like the "Amsterdam Card" in Amsterdam (Figure 5). 
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Source: (Hodges 2007) 

Figure 5: International Fare Cards 

All of these large card systems reflect the high-end extremes of implementation and revenue 
management, but can also provide valuable lessons for smaller deployments. A key element of 
each of them is built around a strong business case for the program. Those cases range from 
regional coordination and revenue management to improved usability for customers and visitors. 

Because of the short time frame and limited scope of all the programs to date, it is difficult to 
identify significant actual impacts and benefits of smart card technology. Contactless cards allow 
faster boarding or throughput than do fare media that have to be inserted or swiped. Higher data 
capacity and processing capabilities of smart cards make innovative types of fare options more 
attractive. 

There are a number of issues related to the use of smart cards that a transit agency must consider. 
The smart card is intended to supplement the agencies' existing paper or magnetic fare media. 
The primary reason for this use of multiple technologies is that smart cards are currently much 
more expensive than magnetic cards or tickets. In order to encourage retention of the smart 
cards, as well to defray their cost, some agencies have imposed a card issuance charge. The fee 
charged by the Washington (D.C.) Metropolitan Area Transit Authority (WMATA) has not 
proven to be a barrier to demand for smart cards to date. According to the agency, sales have 
been evenly distributed among various purchaser income levels, including those with very low 
incomes. High card cost also makes it difficult for an agency to consider providing smart cards to 
one-time or occasional riders, since these people will certainly resist paying a purchase fee. To 
address this issue, much less expensive smart cards, as well as card recycling strategies, are 
currently being developed by the technology vendors. 

One of the key smart card-related concerns in the transit industry has been how to promote 
standardization and interoperability among different technologies. Agencies want to facilitate the 
availability of multiple sources of cards as they introduce smart card systems. In regional 
systems, the integration of fare payment among multiple agencies requires each of the 
participants to be able to accept cards issued by the other participating agencies. Thus, it is 
essential that all participating agencies agree to procure the same system or agree on a common 
technology standard that insures interoperability if agencies select systems from different 
vendors. The contactless card systems implemented to date have utilized several different types 
of contactless interface. Cubic Transportation System, based in San Diego, California, began 
marketing a smart card upgrade for its magnetic systems in the mid-1990s. During this time. 
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Cubic used its own proprietary Go-Card as the basis for upgrading fare systems. The WMATA 
SmarTrip and Chicago smart card systems utilize the latest version of Cubic' s contactless 
communications interface. Cubic has also been awarded contracts to provide cards and 
equipment for several other systems, including those in Los Angeles and San Diego. Regional 
systems now in place or being implemented in San Francisco, Ventura County, Seattle, Berlin, 
Rome and elsewhere are using cards based on a contactless chip developed by Motorola. These 
systems are being implemented in conjunction with ERG, a Cambridge, Massachusetts based 
firm that focuses on several issues, including information technologies. 

Contactless card standards have been the focus of the International Organization for 
Standardization (ISO) 14443 standards development group. Sony, Cubic, and several others have 
sought to have their cards adopted as additional ISO contactless standards, but these proposals 
have not been accepted thus far. In light of the lack of a single technology, or even a single 
standard, vendors have addressed the interoperability issue by developing both cards (actually, 
chips) and readers that combine multiple interfaces. Sharing a common low-level interface does 
not, however, guarantee interoperability. Software communications must also be compatible, and 
there must be shared security data. At the software communications level, different suppliers are 
rarely compatible. 

Major transit card deployments and projects in the United States include Boston's Charlie Card, 
the Washington, D.C. SmarTrip card, the Chicago Card Plus, the Translink card in the San 
Francisco Bay area, Sound Transit in the Puget Sound region and the TAP card in the Los 
Angeles region. All of these projects have gone through a traditional development process and 
have been issued through large private transit-fare vendors. Each of the cards has unique 
applications and characteristics that have lessons for other deployment projects. As a group, the 
Translink, Sound Transit and TAP projects have several unique challenges that serve as valuable 
examples for multi-agency or regional cards. 

The Translink card has attempted to link regional transit fares on nearly every mode of public 
transportation in an area served by 27 separate agencies from very large to very small. The Los 
Angeles card is attempting to link at least 12 agencies and multiple modes. As shown in the 
Puget Sound region as well, establishing business agreements, coordinating services, and 
agreeing to fare arrangements have been significant challenges to the timely implementation of 
the projects. The cards in Washington D.C, Boston and Chicago are primarily single-agency 
cards in their early phases. This has allowed a more concentrated effort toward their deployment 
and a relative streamlining of the business processes. 

Recently, New York's Metropolitan Transit Authority, Washington D.C. Metro and the Utah 
Transit Authority in Salt Lake City have undertaken trials and limited deployments of systems 
that accept payment with standard American Express, Visa and MasterCard RFID chip cards. 
These new approaches appear to promise much lower installation costs, higher levels of 
transaction security and greater customer convenience. These new approaches, based on recent 
industry bids, also offer unique opportunities for sponsoring agencies to explore outsourcing of 
back office, customer support and card distribution functions. Indications are that significant 
operating cost savings, beyond the lower costs associated with the bankcard-based approach, 
may be possible. 

There are several smaller transit agencies that have deployed smart card applications for their 
customers. Ventura County transit in California developed a "home-grown" Go Ventura card 
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system a decade ago in conjunction with the state university. This program was limited in scope, 
but included seven small agencies and is considered to be very successful in the industry as an 
original approach. The program is expected to be folded into the larger Los Angeles system in 
coming years. 

There are numerous other public applications of card technology that directly relate to electronic 
payment business practices and technology. Automated roadway toll collection and settlement 
technologies provide a range of alternative approaches outside the traditional transit industry. 
Numerous standards have been developed in the tolling industry to improve multi-state and 
regional payment settlement and provide customers a seamless trip. The building access and 
security card segments have made huge efforts in improving the security and ease of use for card 
systems. There are several standard cards that are widely available that can be read in an account 
based system and reconciled by a back office operation. Universities, colleges and large 
employers also provide significant opportunities for cooperation in card deployments. All of 
these card-based applications can be integrated into a common, widely distributed and relatively 
inexpensive solution for customers and agencies. 

Numerous opportunities are also present in the public assistance payment arena. Many states, 
including Montana, have issued stored value payment cards that make card accessibility easier 
for customers who may not have available bank resources or debit/credit cards. Various technical 
approaches can be used to improve the payment and record keeping for public assistance 
programs, Medicaid transportation, social services transportation, and senior and disabled 
transportation that leverage existing programs. These technical approaches include using systems 
with open architecture (not linked to the specific vendor), or having the State require new 
systems use common components (such as magnetic stripe versus radio frequency identification 
cards). However, the largest challenges in having common (or flexible) payment/identification 
systems are not technical, but institutional. In many instances, it is the relationship between 
agencies, either at similar levels (Federal, state, regional, etc.) or at different levels, that act to 
prevent coordination and cooperation between service providers. 

It is very important to note that the payment card industry (PCI), led by the large private card 
issuing companies, has developed new card, payment and security standards for small or "micro" 
purchases that provide new opportunities for transportation providers. These standards allow 
immediate verification of small purchases made with American Express' "Expresspay," Visa's 
"payWave" and MasterCard's "PayPass" cards. The financial services industry is providing a 
new avenue for transit operators to develop electronic payment programs using open card 
architectures, widely available readers, secure transactions and opportunities for out-sourcing of 
program operations. None of these areas is new in the payment card industry, but the 
convergence of technology, customer convenience and institutional need is opening up the transit 
payments industry to a higher level of vendor competition. 

Technology and Business Convergence 

As mentioned briefly above, the convergence of technology opportunities in the payment card 
industry and the growing challenges of technology deployments in the transportation and transit 
industries has provided a unique opportunity for several agencies to conduct trials and plan for 
major deployment of electronic payment programs that fall outside of existing vendor offerings 
and may provide major improvements in customer service, transit system management, revenue 
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enhancement and cost savings. There will be some risk as these programs develop, but the 
opportunities provided by lower-cost, more easily managed card systems have triggered a wave 
of interest across the country. 

There are three major pioneering deployments along this line. Washington Metro has fitted its 
subway with RFID card readers that will accept the MetroCard as well as payment with selected 
credit cards directly at the turnstile. The New York MTA is conducting a trial with several card 
vendors using the same approach on New York subways. The most dedicated approach has been 
made by the Utah Transit Authority (UTA) in Salt Lake City. Beginning in 2006, the UTA 
started a demonstration program on its fleet of ski buses to accept payment for transit trips by 
credit card, ski resort employee identification cards, ski season pass holders and a third party 
(Ski Utah) card issued by a separate vendor. The simple intent was to prove that the technology 
for reading and reconciling RFID cards was available and ready for deployment. The 
demonstration was successfully completed in April of 2007. In May of 2007, UTA began a 
process to issue a Request for Proposals for a complete, open source based RFID fare system. 
This deployment will ultimately cover commuter rail, light rail, bus and paratransit services for 
the entire service district. Customers will be able to use their standard credit/debit cards, use 
cards issued through UTA (or a vendor), or use their student and/or employee electronic 
identification cards for fare payment. The open architecture and widely adopted standards are 
anticipated to save the UTA millions of dollars in development and deployment costs over its 
system network. UTA accepted proposals from various vendors and will be announcing which 
vendor is selected in early 2008. 

Payment System Challenges 

The transit industry has a long history with a small number of vendors. Most systems currently in 
place are tied to specific vendors, specific hardware and specific software. Often these systems 
are closed, meaning that the vendor has included special coding or contractual arrangements that 
preclude the customer (transit operator) from using cards or hardware from other vendors. For 
some agencies, this has been a very attractive and useful arrangement. For others it's seen as a 
barrier to deploying lower cost or more widely sourced systems. Working with a single vendor or 
working with a system you already know has its appeal, and changing systems or vendors can be 
difficult. Locking into a specific vendor's product can mean being tied to that vendor's 
development and upgrade cycle, which can be costly. There are few incentives for competitive 
procurements when major system components can only be supplied or modified by the existing 
vendor. This can lead to product obsolescence and significant risk if the sole vendor has 
production or financial challenges. Standards-based open-architecture systems reduce that risk 
by allowing numerous vendors to compete to provide system components. It places a larger 
burden on the management of contracts and business relationships for the transit provider, but 
opens up opportunities for cooperation. 

Another deployment challenge is institutional relationships and system integration. It is not 
common for transportation, social services, medical and disabled service providers to work 
together in coordinating fares and transportation links. Numerous examples exist of revenue 
collection programs that have been delayed or suffer cost overruns because of an inability to 
resolve institutional issues. It is critical that all parties involved in a multi-agency procurement 
or program agree to a common set of business goals and rules during the earliest stages of any 
project. 
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In reviewing some of the projects that have had planning and/or implementation issues, Mr. 
Hodges explains that, "There are usually many fingers to point when large projects fail or are 
delayed. Vendors tend to over-promise technology, software and delivery. Agencies tend to 
have unrealistic expectations about complexity, schedule and cost. Weak project management is 
widely prevalent in the industry and is compounded by poor contracting approaches. Often, 
projects are visualized and agreed to with very little objective analysis and are then later 
expected to perform to a standard that was set after procurement" (Hodges 2008). In Table 1, 
Mr. Hodges noted some of the projects that have not started, or have been significantly delayed, 
and explains his thoughts on the issues of the projects (Hodges 2008). 

Table 1: Technology Deployment Issues 



Project 


Issue 


Discussion 


Translink - Bay Area 


The Translink card is entering a 
second stage of acceptance 
testing with two more operators. 
The initial project was supposed 
to have been completed with all 
27 operators about 5 years ago. 
Full system deployment 
(including Bay Area Rapid 
Transit [BART] and San 
Francisco Municipal 
Transportation Agency [MUNI]) 
could be further years away. 


The project started out as a Metropolitan 
Transportation Commission (MTC) 
project because they had money and 
were a neutral "third party" between big 
and small operators. Numerous 
contractor delays occurred when 
Motorola dropped out of the business 
mid-project and ERG was put in the 
position of technical lead instead of 
supplier. Political conflicts and weak 
project management allowed the program 
to drift for years. Communication also 
drifted between sponsors and agencies as 
time went on. Staff changes and political 
pressure in recent years have gotten the 
program going, but delays have been 
enormous. 


Puget Sound 


When will it happen? 


Political and financial wrangling in 
Washington state and the Seattle area 
have whipsawed this project. Financial 
condition of the contractor may be a 
serious issue. It represents another 
ambitious regional plan that tried to do it 
all at once rather than step by step. 


Houston - Metro 


5+ years of delay led to 
contractor firing for cause and 
damages. Replacement 
contractor is performing well. 


Failure of original vendor to deliver and 
less than optimal contracting from the 
agency let the project drift into a political 
mess. Vendor over-promised technology 
and software, agency neglected to control 
project until it was too late. 


Minneapolis - Metro 


Over one year delay in 
successful installation, testing 
and acceptance of ticket vending 
machines for light rail line. 
Deadline was opening day. 


The project had overly optimistic 
schedule from vendor, especially given 
the project's technical requirements. 
Metro was busy building the line and did 
not dedicate the effort to identify and 
correct vendor until too late. Back office 
software was a major headache beyond 
the technical issues with machines. 
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Table 1: Continued 



Project 


Issue 


Discussion 


Salt Lake City - UTA 


Project bidding and contracting 
delayed nearly 8 months on 
ambitious schedule and new 
technology approach. 


Work in progress. Delays in vendor 
selection threatened ambitious schedule 
from the start. Contract negotiation took 
months longer than scheduled, initial 
start date of April 2008 (from early 2007 
procurement start) will be missed - 
originally scheduled to coincide with 
commuter rail opening. Vendor financial 
position may be an issue. 


Los Angeles, San Diego 


San Diego and TAP cards 
several years behind schedule. 


Overly ambitious schedule that was 
originally tied to success of Bay Area 
Translink. Vendor software issues, 
problems with project management and 
buy-in from agencies. 


Sydney, Australia 


In courts after vendor terminated 
in December 2007. Originally 
scheduled for installation and 
operations prior to 2000 Sydney 
Olympics. Contracted in 1998. 


Ambitious early schedule. Currently in 
court both sides suing for damages. 
Vendor failed to delivery complex 
product, agency made several changes 
along the way. Vendor in serious 
financial condition as a result. 


City in Ohio 


Mid-sized city exploring card 
options. 


Unrealistic financial and technical 
expectations from agency have led to a 
two year postponement of procurement 
when industry vendors could not provide 
a service at the requested cost. 



The issue of consumer privacy and transaction security is another area where the payment card 
industry and transit providers share a common interest. Transportation providers generally have 
no interest in becoming bankers, and banks usually have little interest in providing transportation 
services. However, both parties are legally and ethically bound to protect the privacy and 
security of their customers. The payments industry has stringent standards to protect transaction 
data that no transit provider could easily adopt as its own. To be a card issuer and transaction 
processor would require a major commitment from a transit provider, but could be a task that is 
readily outsourced. Outsourcing of that specific task would also help insulate the service 
provider from any other privacy or security risks. 

Transit providers have different means for collecting fares, billing client agencies, and reporting 
ridership data. In large urban areas, a transit system may use advanced public transportation 
systems (APTS), including fare collection systems that utilize smart cards or stored value cards. 
In small rural areas, transit providers may use cash fares, tokens or punch cards, with information 
recorded manually by the drivers. 
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Rural Technologies 

In rural areas, there have been several different approaches to automated cost recovery 
technologies. In New Mexico, a software system was created to deal with invoicing and other 
issues. In Texas, a transportation provider added on to its existing software to enhance its ability 
to track payments for transportation services. 

In the late 1990s, the Alliance for Transportation Research Institute (ATRI) at the University of 
New Mexico was working with the New Mexico Department of Transportation's Public 
Transportation Programs Bureau (PTPB) on issues such as public and specialized transportation 
funding and coordination. Through this process, it was decided that ATRI would create a 
software program that would allow transit providers, as well as funding agencies such as the 
New Mexico Department of Transportation and New Mexico Department of Labor, to better link 
the payment of rides to their funding source. 

The Client Referral, Ridership and Financial Tracking software known as CRRAFT began 
development in 2000, with initial deployment among a select number of transit providers in 2002 
and 2003. In 2004, the New Mexico DOT required that all rural general public transit providers 
(known as Federal Transit Administration [FT A] Section 5311 providers) use the CRRAFT 
software for invoicing for federal funds obtained through the DOT. ATRI has continued to 
enhance the CRRAFT system to make it more useable for the transit providers, including the 
addition of a Smart Card module to the software in 2005 (the Smart Card module was 
planned/developed in 2004, and implemented in 2005). 

The Smart Card enhancement used off-the-shelf components, and was created to further 
automate the process of tracking ridership and payments. The system (Figure 6) is being used by 
six out of twenty-seven providers in New Mexico (Espinoza 2004). Current information from 
New Mexico indicates that the size of the systems using CRRAFT varies from two to seventeen 
vehicles; with annual ridership from 4,500 to 80,000; operating the spectrum of demand 
response, modified fixed route and fixed route services, or a combination of those services 
(Martinez et. al. 2008 and NMDOT website 2008). 
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Figure 6: CRRAFT System Schematic 

While the Smart Card enhancement was being added to the CRRAFT system, an evaluation was 
taking place to determine the usefulness of the software. This evaluation provides some insight 
as to whether or not the CRRAFT system may be a viable alternative for Montana. 

Twelve hypotheses were developed and tested during the evaluation process. The findings 
(Sanchez 2005) are shown in Table 2. 
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Table 2: CRRAFT Evaluation Analysis 



Hypothesis 


Results 


Use of the system saves transit providers 
time invoicing and reporting to funding 
agencies. 


Not True. On average, the use of CRRAFT has not 
saved transit providers time invoicing and reporting to 
the PTPB. In fact, transit agencies with higher ridership 
and demand responsive service may have had the 
opposite experience and are spending more time 
preparing invoices after the implementation of 
CRRAFl. 


Use of the system results in funding 
agencies having faster access to reports. 


Not True. On average, the use of CRRAFT has not 
resulted in funding agencies having faster access to 
invoices and reports. With the online system however, 
funding agencies may be able to monitor the numbers 
that transit agencies are entering into the system during 
the month. 


Reports created by the system are accurate 
and reliable. Use of the system reduces the 
time funding agencies spend checking and 
correcting reports and reduces money 
incorrectly allocated or invoiced. 


True. The use of CRRAFT has resulted in more accurate 
invoices and has saved time for funding agencies during 
the reviewing process. The fact that transit agencies 
know at all times their remaining balance in each line 
item seems to have helped reduce the number of 
incorrect amounts on invoices. 


Use of the system reduces the time funding 
agencies spend researching and collecting 
information. 


True. The use of CRRAFT has in fact reduced the time 
funding agencies spend researching and collecting 
information. 


Use of the system reduces the overall time 
required for transit providers to schedule 
demand response trips. 


Not True. The use of CRRAFT has increased the time to 
schedule demand response trips for a majority of transit 
agencies, and the impact is particularly evident for 
agencies entering schedule data for many trips. 


Use of the system results in more efficient 
schedules for demand response trips. 


Mixed. For most users CRRAFT did not have a positive 
impact on the efficiency of the scheduled route or the 
development and use of the demand response schedule, 
but may have improved the efficiency for a few smaller 
transit agencies. 


Use of the system reduces the number of 
unauthorized trips. 


Mixed. CRRAFT did not have a clear and decisive 
impact on the number of unauthorized trips. 


Use of the system reduces the number of 
in-service breakdowns. 


Little/no impact. CRRAFT did not have an impact on 
the number of vehicle breakdowns. 
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Table 2: Continued 



Hypothesis 


Results 


Use of the system reduces the operating 
cost of transit services. 


Mixed. For the providers, CRRAFT may result in higher 
operational costs for larger transit agencies that enter 
many demand response trips. However, the data analysis 
did not provide conclusive results about the relationship of 
CRRAFi' with changes in operating cost alone or 
operating cost per trip. 


Use of a web-based system has minimized 
the time and cost of deployment, support, 
and maintenance. 


Mixed. CRRAFT appears to be useful for generating 
invoices and supporting auditing activities, but has 
resulted in many transit agencies doing additional work to 
use CRRAFi' in support of NMDOT reporting/invoicing 
requirements. 


Transit providers and funding agencies 
perceive that the benefits of the system 
outweigh its costs. 


Mixed. NMDOT and New Mexico Human Services 
Department (NMHSD) are generally pleased with the 
benefits of CRRAH' and generally agree that the benefits 
outweigh the costs. The transit agencies have mixed 
views. However larger agencies, particularly those 
providing demand response service, were more likely to 
indicate that CRRAH has been unsuccessful and that the 
costs outweigh the benefits. 


Use of a single system improves 
communication between diverse agencies. 


True. For NMDOT, CRRAFT has resulted in better 
communication and coordination with transit agencies. 
For transit agencies, communication and coordination 
remained about the same or better. 



Funding agencies, including the New Mexico DOT, generally believed that the CRRAFT system 
was an improvement over previous invoicing methods. However, those transit agencies which 
provided a higher number of rides generally believed that the CRRAFT system added to their 
burden, instead of making their operation more efficient. In discussions with several agencies, 
the authors found that those systems that used software to schedule rides felt CRRAFT was a 
burden, although they acknowledged that CRRAFT was easy to use for invoicing, and provided 
lots of reports (Martinez et. al., 2008). 

CRRAFT did not set out to be a computer-aided scheduling and dispatching software, such as 
RouteMatch or Trapeze. The Capital Area Rural Transportation System (CARTS) in Austin, 
Texas, however, designed a system around its Trapeze software. The CARTS system is based on 
adding Smart Card and other technologies to the Trapeze computer scheduling and dispatching 
software that was in place in the organization. The objectives of the project (Marsh 2007) are: 

• Automate fare collection by employing magnetic stripe/smart card readers. 

• Move to paperless, personless reporting and data collection. 

• Integrate Texas "Lone Star" benefit card. 

• Initiate direct billing reporting for Medicaid, etc. 

• Transition to seamless fare media coordination with Capital Metro Transit in Austin, 
Texas. 

Figure 7 and Figure 8 (Mitchell 2007) provide schematic diagrams of the CARTS systems. 
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Figure 7: CARTS Communication Schematic 
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CARTS - Electronic Transactions Process Flow Chart 




Figure 8: CARTS System Schematic 
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The CARTS project was expected to begin system- wide operation in September of 2007, with an 
evaluation of the project to begin six months after full implementation. The evaluation will 
consider the following (Cherrington 2007): 

• Operational efficiency, 

• Data collection, management and reporting, 

• Revenue invoicing and collection, 

• Effectiveness of scheduling, 

• Customer satisfaction, 

• Ability to coordinate services, and 

• Use of swipe card technology. 

While the evaluation of CARTS has yet to begin, the process leading up to the system-wide 
deployment has yielded some valuable lessons (Hosen 2007): 

• Walk, Don't Run-Implement one technology at a time, master it, then take the next 
step. Take your time! 

• A Solution In Search Of A Problem-Have a vision and goals. What do you want to 
accomplish with this technology? What are your technology goals? 

• Purchase For The Future, Not The Present-Think five to ten years into the future and 
ensure that your software will work with any new technologies that may be available. 

• Demonstrations Do Not Really Count-Demos are nice, but you must see the 
technology working in the real world before you purchase. 

• Seek Out The Best Communications Option-In the CARTS case, a local power 
authority was bringing a state-of-the-art system on line. 

• It's Still The Staff-Success depends on staff willingness and ITS capabilities. The 
best technology requires willing and able staff to maximize performance. 

This section reviewed automated cost recovery technologies on a national and international 
scale, including very large (urban) systems, as well as rural systems. The following section 
describes technologies that exist in Montana that could possibly be leveraged as part of an 
automated cost recovery system. 
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CURRENT TECHNOLOGIES IN MONTANA 

There are several magnetic stripe and/or smart card technologies in Montana that could be used 
as the basis for an automated cost recovery system in Montana. However, before a review of the 
cards, it is important to review the purpose of an automated cost recovery system, and how it 
would work in a Montana transit system. 

The purpose of the technology is to automate the collection of fares, and automate (or vastly 
simplify) the process of recording ridership, fare payment, and the processing (or invoicing) of 
those various payments. This focus on the purpose is important, because in Montana the vast 
majority of public transportation (transit) systems are demand-responsive, as opposed to fixed- 
route systems (only 25 percent, or 8 of the 32 public transit systems, have a fixed-route 
component). This difference is important because, unlike a fixed-route service where the rider is 
anonymous, in a demand-response system the ride is scheduled beforehand, so the 
dispatcher/scheduler who schedules the ride knows who is taking the ride and whether there is 
more than one funding source for the ride. In these instances it is not necessary that there be a 
smart card or magnetic stripe card, and a basic computer-aided scheduling and dispatching 
software may be all that is necessary. 

Most computer-aided scheduling and dispatching software programs greatly simplify the process 
of managing customer/rider data, and can easily determine how many rides were provided from a 
given funding source or through a particular payment method. There are two transit systems, 
MET Transit in Billings and the Great Falls Transit District, that are using current computer- 
aided scheduling and dispatching software. MET Transit acquired RouteMatch software 
(Adanta, GA) within the past three years (Appendix D), and Great Falls Transit uses Shah 
software (Midland, TX). Mountain Line in Missoula currently uses Paralogic software (Orlando, 
FL) although there is discussion that Mountain Line may issue a Request for Bids for new 
software within the next year or two. 

Because RouteMatch software has been used in a statewide application, it is known that the 
software could be leveraged to a statewide system (though with additional costs). It is not 
known at this time whether or not the Paralogic or Shaw software systems could be leveraged to 
create a statewide network. The decision on which software to select would be based on creating 
specifications that were not part of the scope of work of this project. However, if the decision is 
made to move forward to further investigate automated cost recovery technologies, it would be 
wise to further investigate the three software systems being used in Billings, Great Falls and 
Missoula. 

In addition to the transit/paratransit software systems, the WTI team identified several other 
technologies in Montana that could be utilized for automated cost recovery purposes. These 
technologies include the Montana Access Card and the "Griz" and "Cat/One" cards that are 
associated with the University of Montana and Montana State University, respectively. Even the 
Montana state driver's license could be used as a fare card for an automated cost recovery 
system. These cards could be employed in such a way that they are the only card accepted by a 
system, or an automated cost recovery technology (card reader) could be designed to read a 
number of different cards. 

In Missoula, the Mountain Line system uses GFI Genfare fare boxes that can read a number of 
different magnetic strip cards, including the Griz card and the passes that are produced by GFI 
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Genfare. Additional cards could be read by the system, as long as GFI Genfare knew where the 
information was coded on the particular magnetic strip. If a card system was implemented in a 
particular area, or on a statewide basis, it would be possible to read a number of different cards, 
if that were deemed desirable. 

The requirements analysis conducted, and discussed in the next section, considered these cards 
and used a survey to determine what additional technologies may already be in use by transit 
systems in Montana. The purpose of the requirements analysis is to ensure any future 
systems/technologies that are defined for automated cost recovery systems (a potential follow-on 
project) are interoperable, expandable, and compatible to the maximum extent possible with 
current technologies that may be deployed (or soon deployed) in transit systems in Montana. 
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REQUIREMENTS ANALYSIS 

The WTI team conducted a survey that documented payment methods and invoicing/reporting 
requirements of public and specialized transit providers across the state. The survey also 
examined current technologies used by providers, and funding sources related to current 
passengers. This process helped define what systems/technologies may be implemented in the 
future by transit agencies. These systems/technologies may assist with a number of functions, 
including fare payment, cost recovery, ridership tracking, automated reporting to agencies such 
as MDT and the Department of Public Health and Human Services (DPHHS), etc. 

The survey was mailed to 73 public and specialized transportation (transit) systems in Montana 
to collect information that would be used in the cost/benefit and implementation tasks within this 
project and report. The survey consisted of four sections: organizational characteristics, reporting 
requirements, organizational business practices, and organizational use of technology. The 
questions in these sections were intended to collect information on transportation (transit) 
agencies in Montana to determine how transit operators are tracking ridership, fare payment, and 
what technologies are being used in their operations. Thirty-four surveys were returned for a 
response rate of 46 percent, which is a high return rate for a mail survey, considering no follow- 
up was made after the surveys were initially mailed. Based on the responses from a range of 
providers, we believe that the survey results are representative of all transportation providers in 
Montana. A copy of the survey instrument is included as Appendix A, while a summary of the 
responses is included in this section, with detailed responses provided in Appendix B. 

The percentages associated with the various answers to each question are based on the total 
responses to the question, not the number of surveys received. Therefore, if only 20 
organizations responded to a question, the percentages of the various answers are based on a total 
of 20 answers and not the total of 34 surveys returned, unless otherwise noted. The summarized 
responses of each question are shown in Table 3. The detailed list of all responses to each 
question, along with any comments is included in Appendix B. 
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Organizational Characteristics 


Question 


Response Summary 


Does your organization collect fares (payments) from 
any individual who rides your vehicles? 


Yes: 65% 

No: 35% 


How are fares collected 


Most systems use a variety of methods, including cash 
fares, punch cards and (monthly) passes. 


Does your organization collect ridership data? 


Ninety-seven percent of the respondents (33 out of 34) 
indicated that they do collect ridership data. 


How is data collected? 


The majority of the systems have the driver collect the 
information on either a tally sheet, or with a 
mechanical counter/clicker. 


How does your organization define a 'ride' (e.g., round 
trip, one way, or other)? 


76%: ride = one way trip 
35%: ride = round trip 


What is the approximate total number of customers you 
have of each type noted, and what is the approximate 
number of monthly rides you provide for each customer 
type noted? 


Responses for each agency are listed in Appendix B 


Approximately how many new customers (not existing 
customers) do you add to your service each month? 


Responses varied from zero to fifteen. The majority of 
respondents (15 out of 33) noted that they add 
between one and five new customers each month. 


What is the total number of vehicles operated by your 
organization, and what is the number of vehicles (for 
carrying passengers) operated by your organization? 


Average number of total vehicles: 8.3 

Average number of vehicles that carry passengers: 6.7 


Do you have passengers whose rides may be paid for 
by a variety of programs or sources? If so, please 
indicate the maximum number of different sources or 
programs that may pay for one customer's rides. 


35%: have clients with at least one funding source 
24% : do not have these clients 
41%: Question not applicable 


Does your organization also pay for rides using 
vouchers, or pay taxis or other sources (such as family 
members) to transport an individual? If so, please 
describe these various methods/modes your 
organization uses for transportation services. 


62%: Do not pay for other rides 

12%: Pay for other rides (bus passes or vouchers 

26%: Question not applicable 


Reporting Requirements 


What information, if any, pertaining to ridership and 
fares do you report to any other organization? 


23 agencies (68%) report to MDT 

2 agencies report to National Transit Database 

1 agency report to something "other" 

8 noted what they reported 


How does your organization collect and report 
information pertaining to ridership and fares? 


The majority of respondents indicated that 
information from the driver's "tally sheets" are 
combined (typically in a spreadsheet program) and 
may be included with financial information before 
being reported. The majority report the information on 
a quarterly basis. 


Does your organization have any issues and/or 
challenges with the current system you are using? If so, 
what are the issues? 


76%: No issues (or blank) 

24%: Have issues (i.e. human error, system is paper 

intensive, system provides inaccurate info) 


Do you have any suggestions for improving the data 
collection and/or reporting process? 


88%: No suggestions (or blank) 

12%: Have suggestions (i.e. smart cards, direct online 

reporting, electronic collections system) 
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Table 3: Continued 



Business Practices 


Question 


Response Summary 


If your organization collects ridership and/or fare 
information, how does that data/information move from 
the vehicles into the office? 


87%: Tally Sheets 

10%: Driver 

1 response: electronic submission 


If your organization reports data to other 
agencies/organizations, how do you do that? 


42%: online/e-mail 
12%: hard copy/paper 
32% use both methods 


If your organization invoices another 
agency/organization for rides, how do you do that? 


20 responses: question not applicable 

32% (of those listing method): hard copy invoice 

2 responses: online/e-mail invoice 


Technology Use 


Does your organization have fare boxes in any of the 
vehicles it uses for passenger transportation? If yes, 
does your organization use the fare box to track 
ridership? 


24 respondents (70%): no fare boxes 

6 respondents (18%): have fare boxes (only one uses it 

to track ridership) 


Does your organization have any other technology on 
the vehicles it uses for passenger transportation, such as 
automated passenger counters, automatic vehicle 
location systems, etc.? If so, please describe the 
technology or technologies. 


Four respondents with other technologies: 

1 two-way radio system 

2 AVL systems 

1 personal GPS receiver 


When your organization tracks ridership, does it use 
spreadsheets or other computerized, electronic methods 
for tracking ridership? If so, please explain the methods 
(systems) used. 


17 responses (50%): no electronic tracking 
16 responses (47%): Excel spreadsheet 
1 response (3%): MDT form 


Describe any other systems or technologies your 
organization uses in the process of carrying passengers, 
including tracking expenses, invoicing, reporting, etc. 


4 responses: Quicken/Quickbooks 
1 response: Microsoft Excel 
1 response: "accounting system" 
1 response: "computer" 



When analyzing the responses from the questionnaire, it became apparent that a follow-up 
question was necessary to determine how much time the transit providers were spending on 
tracking ridership and fares, and creating invoices. Therefore, a follow-up question was sent (via 
e-mail) to those who had responded to the initial survey. In general, the question asked the 
amount of time the organization spent, either on a daily, weekly or monthly basis, tracking 
ridership and fares/payments for transportation (transit) system. 

In addition to the original e-mail, a total of three follow-up e-mails were sent. However, only ten 
responses were obtained from the 34 providers. To standardize the data to an annual basis, 250 
service days are estimated, or 52 weeks of service. The responses ranged from 24 hours to 1,250 
per year. The average among the ten responses was 313 hours per year, but five of the ten 
responses were in the range of 80-150 hours. The detailed information on the responses in is 
Appendix B. 

In summary, the responses indicate that the majority of public and specialized transportation 
(transit) providers in Montana use manual (or paper) methods for tracking ridership and fares. 
While many agencies use Microsoft Excel or other software (Quick Books) for summarizing 



Western Transportation Institute 



Page 25 



Automated Cost Recovery: A Feasibility Study Requirements Analysis 

information, the information that feeds into these programs comes from manual collection 
systems. Our research was able to find only one transit system, Mountain Line in Missoula, 
which uses electronic fare boxes to track ridership and collect fares. In addition, while the 
amount of time systems spend tracking ridership and fares varies, the majority of respondents 
spend between 80 and 150 hours per year (6.7 to 12.5 hour per month) on this task. 

One issue that transportation providers face when tracking ridership is compliance with the 
Americans with Disabilities Act (ADA). The following section describes ADA and how it relates 
to automated cost recovery systems. 
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AMERICANS WITH DISABILITIES ACT (ADA) ISSUES 

The WTI team reviewed the requirements of the Americans with Disabilities Act (ADA), and 
considered how the various automated fare recovery technologies may be affected by ADA 
guidelines. Due to the nature of transit systems and service in Montana, a sizeable percentage of 
riders/customers are persons with disabilities. It is therefore important to make sure that the 
automated cost recovery systems would be as compatible as possible for people with various 
levels of abilities. 

The basic intent of the ADA is to ensure that all Americans have access to transportation 
services. A combination of laws, administrative regulations, legal settlements and generally 
accepted practices has defined the scope of the ADA program for public transportation. 
Generally, there are few guidelines regarding the function of fare collection systems, but there 
are rules and regulations concerning the dimensions and placement of equipment and the fare 
amount that may be charged for eligible customers. Most transportation providers have 
established certification processes for disabled customers. These certifications provide a 
framework for the providers to operate their services and manage their customer interactions. 

Operational and Customer Considerations 

There are operational, financial and managerial considerations that merit a closer look when 
considering an automated fare and revenue management system. From an operational standpoint, 
automated fare collection can enhance system accessibility and system efficiency. It can 
encourage system use and can also be a tool to guide customers to services that may be more 
effective for them and for the service provider. Automated fare collection can help providers 
reduce dwell times, reduce payment delays and provide customers a better way to manage their 
transportation budgets. Occasionally, disabilities such as visual impairments, cognitive 
impairments, intellectual disabilities, and disabilities that involve motor function make it difficult 
for passengers to navigate systems and make fare payments. Automated payment systems hold 
the promise to ease some of that difficulty and improve customers' abilities to successfully 
complete their trips. Pre-paid cards or cards that can be managed on-line by the customer or 
others also provide opportunities to more effectively manage personal travel budgets. Those 
system benefits are also passed on to non-disabled passengers and customer groups such as 
seniors, students and children. It is imperative that local interest groups in the disabled 
community and the medical community are involved from the beginning in discussions and 
design considerations. 

Agency Considerations 

From a revenue management standpoint, automated payment systems can improve the 
management and coordination of the numerous funding programs that subsidize disabled 
transportation services. The software and management tools that these systems bring in to 
agencies can also provide reporting and accounting advantages to both the operator and to 
agencies that interact with them. If agencies are willing to cooperate in the development and 
implementation of coordinated revenue management systems, service duplication can be 
decreased and reporting requirements can be more effectively implemented. 
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Suggested ADA Minimum Requirements 

An operational payment system that respects the spirit and law of the ADA should, at a 
minimum, have the following capabilities: 

Provide access to fareboxes, validators and readers that meet ADA physical design 
standards. 

Provide media that are easy to identify and manipulate for all customers. 

Determine proper fare payment. 

Correctly activate and validate fare cards. 

Correctly update customer account information (for example, deduct one trip from 10 
trip pass and add applicable transfers). 

Record fares collected by trip and vehicle. 

Record all fares with date, time and location. 

Provide driver the ability to input events to be recorded. 

Provide managers with the tools necessary to effectively operate their systems. 

Provide an acceptable audit trail for transactions from the customer's viewpoint, 
regulatory review and the agency's needs. 

ADA considerations will need to be addressed when any type of system is in its "requirements" 
phase. The types of fare media used, the placement of any card readers, etc., will all need to be 
addressed if an automated cost recovery system is to be planned and implemented. 

A major factor in determining whether or not to implement an automated cost recovery system is 
the benefit/cost analysis of the proposed system. The following section describes the benefit/cost 
analysis of various technologies that would likely be part of an automated cost recovery project. 
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BENEFIT/COST ANALYSIS 

All programs and projects require some level of analysis to determine whether the project should 
be undertaken. Assessments should extend beyond simple rate-of-return calculations when the 
impacts of an approach extend beyond financial considerations. Basic analysis can help address 
the most effective way to achieve a business goal and forms the basis of supportable decisions. 
Included in each analysis should be a discussion of the "do nothing" choice. That baseline sets 
the context for comparing options. 

This section looks at the benefit/cost analysis from several perspectives, analyzing basic risk 
factors, discussing benefit/cost analysis from other projects, and then looking at a break-even 
analysis to describe what level of benefits may be necessary to obtain a positive benefit/cost ratio 
(a ratio of greater than 1.0) 

Benefit/Cost Analysis Foundation 

Benefit/cost analysis (B/C) is a tool to directly compare relative costs and expected returns from 
a project. B/C analysis can be challenging when dealing with technology-based investments and 
often needs to be supplemented by further complementary analyses. The context of the analysis 
revolves around basic questions of whether the project should be pursued, what gains are 
expected, what business goals can be achieved, timing and, fundamentally, can it be done under 
the constraints of the situation. 

Benefits tend to cross a range of values and interest areas. Direct benefits are easiest to measure 
as the final product or service to new or existing customers. Indirect benefits are those that 
support the final outcome, but also include efficiency benefits for partner agencies, policy 
coordination benefits, reduced costs, perceptions of convenience, etc. Benefits are distributed to 
implementing agencies and their customers in both tangible and intangible forms. Generally, 
tangible benefits are new customers, new revenues and new services. Intangibles range from 
convenience, improved information flows, improved public image, and political or business 
gains. It is often difficult to place a monetary value on intangible benefits. If any assumptions are 
made about the value of these benefits, they need to be clearly stated in the B/C calculation. All 
benefits must therefore be gathered and evaluated in a similar fashion. 

Costs are estimated by gathering quantifiable direct financial costs, and less apparent indirect 
costs such as opportunity costs, inefficiency costs, and exiting costs (the costs that may 
accompany ending the use of an existing system). At times, it is difficult to estimate costs, so it is 
important both to make reasonable assumptions and to clearly state them. The basic structure of 
the analysis is to formulate year-to-year direct costs, add operations and maintenance costs over 
the expected project lifecycle. This analysis of costs leads to the total project costs that will be 
compared against the projected project benefits. 

Once the total benefits and total costs are calculated, the monetary value of the benefits of the 
project is divided by the monetary value of the costs of the proposed project. If the ratio is 1.0 or 
greater, the project is expected to pay for itself — that is, the benefits received are greater than the 
costs involved. It is important to note, however, that a project may be implemented without a 
B/C ratio of 1.0 or greater. An agency or organization may undertake a project for political or 
other "intangible" reasons, knowing that a project may not pay for itself. In these instances, 
however, it is important that everyone involved is aware that, although the B/C ratio is not 1.0 or 
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greater, the project is being implemented for other reasons. The implementation of the Puget 
Sound Regional Fare Coordination project is such an example. When asked about the potential 
B/C ratio of the project, Candace Carlson from King County Metro did not yet have a conclusive 
answer (Carlson 2006): 

Question: The overall system cost appears to be approximately $70 million. Are there any 
savings from the Smart Card system that have been quantified and projected? 

Answer: We did some baseline studies of about four of the agencies. We will revisit those. 
Those were looking at operating functions, primarily those back office functions of handling all 
of the fare media, the accounting, and also looking at fare box maintenance, that kind of thing. 
We'll take a look at those. They all project some kind of break-even or slight savings. We'll see 
how that holds. 

Depending upon the length and complexity of a project or projects, a net present value (NPV) 
calculation may be utilized. The NPV calculation allows the analysis of benefit and cost values 
in relationship to the long-term monetary costs of a project. The general cautions about B/C 
techniques include appropriate classification of benefits and on-going costs and the use of NPV 
calculations. Additionally, notes about funding constraints, policy issues and risk are commonly 
attached to the discussion of the analysis. 

Risk Assessment and Sensitivity Analysis 

It is important to remember that few technology investment projects have flawless 
implementations. There are a wide range of factors that have an impact on the success of a 
project. It is not necessary to test unlimited possibilities, but notice should be made of risk areas 
and their probabilities. Risk areas include technology, vendor performance, policy conflict, 
institutional issues, and financial risk for partners. Evaluators and decision makers must 
ultimately decide what level of risk to accept and how to manage it. There are many good 
strategies to manage risk, including segmenting large projects into smaller steps, low-cost testing 
of new technologies, transferring some risk through contracts, and increasing levels of design 
before purchasing decisions are made. The agencies involved should make the determination 
based on their experience, the evaluation data and their level of risk acceptance. 

Table 4 provides a high-level assessment of the risks associated with the Auto Cost Recovery 
(ACR) project. The rankings were done using a High-Medium-Low scale and are based on 
information gathered from existing projects, industry publications and evaluation assessments 
prepared by project sponsors around the country. 
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Table 4: Auto Cost Recovery Project High-Level Risk Assessment 




Payment 
Approach 


Implementation 
Cost 


Implementation 
Level of Effort 
(Agency Risk) 


Technology 
Risk 


Gain from 
Incomplete 
Implementation 
(Partial Benefits?) 


Benefit Level 
in Relation to 
Project Goals 


Traditional 
"Cash and Pass" 


Low-Med 


Low 


Low 


Low 


Low 


Magnetic Stripe 
Card 


High 


Med 


Low 


Med 


Med 


Transit Smart 
Card 


High 


High 


Med-High 


High 


High 


Other type cards 


High 


Med 


High 


Med 


Med-High 


Micro-Payment 
System 


Low 


Low 


Med 


High 


High 



Before the benefit/cost analysis of potential automated cost recovery projects in Montana is 
discussed, it is important to review the B/C analysis (or lack thereof), of some projects noted in 
previous sections. 

In the Puget Sound area, a total of seven organizations are planning to spend $70.5 million over 
the next ten years to implement a smart card solution to allow a single fare source. $41.8 million 
is for capital costs, while $28.7 million is expected to be spent on operational costs over the ten 
years. As indicated by the exchange noted above, the organizations spending this money hope to 
break-even (benefits equal costs) or see slight savings (benefits are slightly higher than costs). As 
with many projects, the true B/C ratio will not be known until after the project has been 
implemented, and perhaps not known for a number of years. 

The CRRAFT project was discussed in a previous section, and an evaluation of that project was 
noted in Table 1. Unfortunately, a definitive B/C analysis was not conducted. As noted in the 
report, "As archived cost data were unavailable, the emphasis is on the opinions of the transit 
providers and funding agencies on whether the CRRAFT benefits outweigh its costs." Without 
analyzing the specific costs of creating and implementing the CRRAFT system, it is impossible 
to determine if it has a positive B/C ratio. Another technology project in a rural setting, the 
CARTS project, does not have a B/C ratio. This is due in part to the fact that many parts of the 
system did not "go live" until late fall in 2007. It would certainly be helpful to any future 
Montana transit technology projects if a B/C ratio is eventually calculated for the CARTS 
project. 

The technologies being implemented as part of the CARTS project have cost about $400,000 to 
date. When the initial budget was set at $256,000, it was estimated that the project would have a 
five-year payoff. It is unknown at this time how much the project will ultimately cost or how 
long it will take to pay for itself. 

The final project noted before looking at the analysis for Montana projects is the South Carolina 
Virtual Transit Enterprise (VTE). This project was started in 1996. In 1999, the original plan was 
finalized as shown in Table 5 (Schwenk 2005). 
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Table 5: Four-Point VTE Approach, September 1999 



Point 


Definition 


Goal 


Point 1: 


Information Sharing with 
External Entities 


Develop a structured method for selected public 
provider functions to interface with external 
entities electronically, to benefit all 1 8 public 
providers. 


Point 2: 


Integrated Automated Fare 
Collection (AFC) 


Integrate AFC technology at one Working 
Proveout site and integrate a shared passenger 
accounting system to benefit all 18 pubhc 
providers and to provide SCDOT with more 
timely ridership data. 


Point 3: 


Improve Grants/Contracts 
Making, Administration, 
Reporting and Invoicing 
Processes 


Develop a mechanism to improve the Grant 
Making, Grants Administration, Reporting, and 
Invoicing process conducted between 
SCDOT/DMT and the 18 pubhc providers that 
receive funding through SCDOT/DMT. 


Point 4: 


Scheduling and Dispatching 
(S&D) Integration with AVL 


Integrate Scheduhng & Dispatching (S&D) with 
an ITS-compliant AVL system. Target one of the 
public providers as a Working Proveout site, and 
estabhsh standard procurement specifications, 
which other public providers can use to build their 
S&D and AVL systems. 



While this approach has been modified, and the project is not yet considered concluded, a total of 
$2,510,473 had been spent as of November 2004. The evaluation of South Carolina's Virtual 
Transit Enterprise did not provide a B/C analysis. As we look at the B/C ratio for potential 
automated cost recovery projects in Montana, it is important to note that many projects that have 
been, or are being implemented, have not included specific information on B/C ratios. The 
Billings MET Transit project included herein as Appendix D, however, is one of the few 
evaluations specifically addressing the B/C analysis. 

Benefit/Cost Analysis for Potential Montana ACR Projects 

As noted in the previous section, there have been automated cost recovery and other technology 
projects that have been implemented either on a statewide basis (e.g.. South Carolina, New 
Mexico), or on a local/regional level (Puget Sound, CARTS). One of the issues in identifying the 
benefit/cost ratio for any project will be the size and scope of the project, and whether the 
technologies will be implemented on a statewide or local/regional basis. No matter how the 
projects may be implemented, there are some fundamental issues that should be considered for 
any potential automated cost recovery projects (Table 6). 
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Table 6: Automated Cost Recovery Project Matrix 



Task 


Value/Purpose 
to Agency 


Process 


Metric 


Goal 


Fare verification at point of purchase 


Cash payment 
verification 


Reduced fraud, 
underpayment 
and misuse 


Survey and 
correlation with 
fare box receipts 


Average 

percentage of non- 
payment or 
underpayment 


Opportunity for 

revenue 

improvement 


Pass verification 


Reduced fraud 
and misuse 


Ride along survey 
or observations 


Average 

percentage of pass 
misuse or fraud. 


Improved media 
security and 
revenue 


Transfer, Token, 
employee and 
dependent 
verification 


Reduce fraud, 
misuse and 
allow tracking 
of "other fare 
category" use 
rates 


Ride along survey 
either with pass 
study or cash study 
- correlate 
transfers received 
for validity 


Average 
percentage of 
transfer misuse or 
fraud 


Improved security 
and revenue 


Event Recording 


Block/Route level 
revenue reporting 


Enhancement 
of route level 
analysis - 
improved 
decision 
making 


Integrate 

passenger boarding 
and revenue data 


Increases in 
route/trip level 
analysis 


Improved decision 
making using cost 
per rider metric. 
More productive 
service delivery 


Census Passenger 
Boardings 




Estimate costs of 
manual or 
automated process 
using labor, APCs 
or other technology 


Cost comparison - 
Opportunity cost or 
alternative cost 
comparison 


Policy level 
reporting 


NTD Data 
Collection 




Opportunity cost 
comparison 


Relative cost 
comparison 


Transfer of data 
collection costs to 
automated system 
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Table 6: Continued 



Task 


Value/Purpose 
to Agency 


Process 


Metric 


Goal 


Fare Collection Process Management 


Flexibility in fare 
policy 


Management 
tool 




Allows 

development of 
effectiveness 
measures 


Improved 
management of 
revenue policy 


Flexibility in fare 
media 


Marketing tool 


Collect annual 
printing costs for 
monthly media 


Cost comparison 


Better customer 
responsiveness, 
improved customer 
interactions, 
partnerships 


Reduced Operator 
- Passenger fare 
conflicts 


Customer 
service, driver 
job satisfaction 


Survey for 
perceived levels of 
fraud, suggested 
improvements in 
physical devices 
and procedures 


Rankings and 
comparison 


Buy in. Operators 
are a primary 
customer in this 

system 


Improved reporting 
management and 
tools 




Estimate of 
alternatives 


Cost substitute for 
manual collection 


Better revenue 
management and 
decision making 



In general. Table 6 notes that automated cost recovery projects should help track ridership, fare 
collection, and data management (reporting, invoicing, etc.). An automated cost recovery project 
should only be implemented if it addresses these issues and has a benefit/cost ratio of 1.0 or 
greater. If the proposed project does not have a benefit/cost ratio of 1.0 or greater, those involved 
in the project should recognize that issue and explicitly state why they would implement the 
project anyway. 

Project Options 

As noted earlier in this document, the majority of public and specialized transportation providers 
in Montana operate on a demand-response basis. Therefore, few systems would receive 
significant benefits from implementing a farecard system, whether the card was a magnetic stripe 
or smart card. Another important consideration is that the three largest public transportation 
providers in Montana-Billings, Great Falls and Missoula-operate independently of the Montana 
Department of Transportation. These three systems operate under the Federal Transit 
Administration's (FT A) program known as Section 5307, which means that these systems deal 
directly with the FTA, and not MDT. Therefore, if MDT wanted to implement any system on a 
statewide basis, these three systems would do so on a voluntary basis. 

The benefit portion of the analysis for each option includes any possible reduction in staff time 
for the transit providers and other agencies, and the recovery of additional fares. Intangible 
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benefits that are harder to measure include more real-time information for agencies such as MDT 
and DPHHS, as well as the potential for reduced time between submitting an invoice and the 
payment of the invoice (such as with electronic invoicing). Further, an electronic system may 
allow for daily or weekly invoicing, whereas now that invoicing may take place on a monthly or 
quarterly basis. 

The cost portion of the analysis includes any upfront expenses such as hardware and software 
purchases and maintenance costs. Any communications costs will also be included in the cost 
portion of the benefit/cost analysis. 

The benefit/cost analysis herein is based on averages-the average benefits a transit system may 
receive, and the average costs for the various technologies. It is important to remember this, as 
one system may receive more benefits from a particular technology. Also, depending upon the 
specific technology and vendor selected, the actual costs may be more or less than what is 
indicated in this report. 

It is also important to note with the analysis that many transit systems are able to utilize federal 
funds to help purchase software and other technologies. Federal funds may provide from 80 to 86 
percent of the technology costs. For example, if a system were to cost $100,000, only $14,000 to 
$20,000 in local funds may be needed. The transit system would only truly need to recoup the 
local share for the system to be beneficial. The analysis of the various options noted below show 
the entire amount of benefits and costs. In addition, the analysis will show the difference 
between treating costs as "total costs", or showing the analysis based on "local costs," the funds 
that the local transit agency would have to pay. 

Customer/Rider Management Software (Basic) 

As noted previously, many of the public and specialized transit systems in Montana are demand- 
response systems, which means the customer must call to schedule a ride. The transit system 
therefore would know who is taking rides and the payment source for those rides. Valley County 
Transit is now providing same-day demand response rides, and those rides are more demanding 
to schedule than a traditional demand response ride. In the case of a same-day demand response 
ride, the ride is more of a fixed route ride, than a demand response ride. Provided that the 
demand response system has information on their rider, they would likely benefit from customer 
(rider) management software than from providing farecards to their riders. As noted in the 
survey results, of those transit systems responding to the survey that reported using software, 
most reported using Microsoft Excel and a few used QuickBooks. Therefore, a basic software 
system that tracked ridership and payments could be beneficial to many of the transit providers. 

There are various software programs for transit agencies, ranging from basic programs such as 
Shah Software and Mobilitat, to advanced software such as RouteMatch, Strategen and Trapeze. 
The more advanced software will be discussed later. Here we will focus on basic customer 
management software. 

For a basic software system, the costs will be the software, annual maintenance costs and, if 
necessary, a computer. If the software system were based on the agency's own computer, it is 
anticipated that there would be no increase in communications costs, or any other costs 
associated with the software. If the software were installed on an off-site server, and accessed 
through the Internet, some transportation providers may face increase communication costs as 
they may be required to upgrade their Internet access. 
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Benefits accrued from employing the software would be a reduction in time tracking ridership, 
fares, and invoicing the funding sources. To determine the potential benefits to transit systems, a 
follow-up question was asked of representatives from the 34 systems that completed the original 
automated cost survey. They were asked how much time their organization spends tracking 
ridership and fares/payments (Appendix B). Based on the range of responses, and variation in 
how much staff may be paid, a range of variables are included in this analysis so that different 
sized systems can determine whether or not an automated cost recovery system may be 
beneficial to them. 

Costs (five-year timeframe) 

Software = $19,500 (estimate, initial purchase) 

Maintenance Fee = $12,000 ($3,000 per year for years 2 through 5) 

Computer = $0 (assume agency has a computer) 

Total costs for five years = $31,500 

Benefits (five-year timeframe) 

Reduction in time to track ridership, fares and invoicing (time savings as noted, estimated to be 
75% of current/existing time), and hourly employee rates include taxes and benefits. 

Intangibles: near real-time information, better customer service 

Information on the benefit/cost ratios for transit systems, based on the hours they spend on 
tracking ridership, fares, etc. is provided in Table 7. 

Table 7: Benefit/Cost Analysis-Basic Software 



Annual Time Savings 


Employee Rate (hourly basis) 


5-year Savings 


Benefit/Cost Ratio 


90 


$10 


$4,500 


0.143 


90 


$15 


$6,750 


0.214 


90 


$20 


$9,000 


0.286 


225 


$10 


$11,250 


0.357 


225 


$15 


$16,875 


0.536 


225 


$20 


$22,500 


0.714 



Savings of $6,300 per year ($31,500 for five years) would be necessary to achieve a benefit/cost 
ratio of 1 .0 or higher. 

Note: Software costs may be reduced if a group purchase were made. 

Computer-Aided Scheduling and Dispatching Software (No in-vehicle technology) 

This analysis is very similar to the analysis conducted for MET Transit (Appendix D). The use of 
computer-aided scheduling and dispatching software not only helps with customer/rider data, it 
also helps develop the routing of the vehicles in a demand-response system. This is particularly 
helpful in systems that operate more than five or six vehicles on a daily basis. It is hard for a 
human being to optimize the schedule for more than that number of vehicles, considering the 
time and location variables among the rides requested. Transit systems using these technologies 
have seen dramatic increases in efficiency and, as shown in the MET report, a decrease in service 
hours or mileage of three percent is all that is needed for the software to pay for itself. As noted 
earlier, the three large transit systems in Billings, Great Falls, and Missoula deal directly with the 
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Federal Transit Administration and not MDT, and therefore may not be part of a statewide 
project. Also, since many of the transit systems in Montana only operate a few vehicles (fewer 
than six) in demand-responsive service, this software would provide less benefit to them than it 
would to a larger system. 

Costs (five-year timeframe) 

Software = $80,000 (estimate, initial purchase) 

Maintenance Fee = $44,000 ($1 1,000 per year for years 2 through 5) 

Computer = $3,000 (assume agency needs two powerful computers) 

Total costs for five years = $127,000 

Benefits (five-year timeframe) 

Reduction in time to track ridership, fares and invoicing (time savings as noted, estimated to be 
75% of current/existing time), and hourly employee rates include taxes and benefits. 

Intangibles: near real-time information; better customer service; potential for reducing time and 
mileage of transit system (although less likely for small systems). 

Table 8 shows a range of benefit/cost ratios for C ASD software. 

Table 8: Benefit/Cost Analysis-CASD Software 



Annual Time Savings 


Employee Rate (hourly basis) 


5-year Savings 


Benefit/Cost Ratio 


90 


$10 


$4,500 


0.035 


90 


$15 


$6,750 


0.053 


90 


$20 


$9,000 


0.071 


225 


$10 


$11,250 


0.089 


225 


$15 


$16,875 


0.133 


225 


$20 


$22,500 


0.177 



In addition to the savings from ridership, fare and invoicing, a transit system would need to save 
anywhere from $20,900 to $24,500 per year in other operational costs to achieve a benefit/cost 
ratio of 1 .0 or higher. 

Notes 

As previously noted, computer-aided scheduling and dispatching software has greater benefits 
for larger systems (five or more vehicles). Furthermore, the software cost may be reduced if a 
group purchase were made or if the system were implemented on a statewide basis. However, 
trying to implement a system on a statewide basis is not inexpensive. For example, South 
Carolina spent just over $2.5 million from February 1996 to November 2004 on its Virtual 
Transit Enterprise. 

Computer-Aided Scheduling and Dispatching Software (with in-vehicle technology) 

This option would take the computer-aided scheduling and dispatching software noted in the 
previous option and link it to mobile data computers (Appendix C) that would be placed in the 
demand-responsive (and potentially even the fixed-route) vehicles. Billings MET Transit is 
exploring adding mobile data computers to its vehicles. The benefit of the mobile data computer 
is that it "talks" to the software, so that a dispatcher can see if a vehicle is falling behind in its 
schedule. If so, the driver can shift rides to vehicles that are on-time or ahead of schedule. 
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Mobile data computers also reduce the amount of time drivers need to communicate on the radio, 
and can be used to capture data electronically (such as when passengers are picked up and 
dropped off) for reporting and management purposes. 

Costs (five-year timeframe) 

Software = $80,000 (estimate, initial purchase) 

Maintenance Fee = $44,000 ($1 1,000 per year for years 2-5) 

Computer = $3,000 (assume agency needs two powerful computers) 

Mobile Data Computers = ($3,065 per vehicle, 10 vehicles) 

Additional Hardware/Software = $12,065 (tied to mobile data computers) 

Total costs for five years = $169,715 

Benefits (five-year timeframe) 

Reduction in time to track ridership, fares and invoicing (time savings as noted, estimated to be 
75% of current/existing time), and hourly employee rates include taxes and benefits. 

Intangibles: near real-time information; better customer service; potential for reducing time and 
mileage of transit system (although less likely for small systems). 

Information on the range of benefit/cost ratios is provided in Table 9. 



Table 9: Benel 


Fit/Cost Analysis-CASD Software & In-vehicle Technology 


Annual Time Savings 


Employee Rate (hourly basis) 


5-year Savings 


Benefit/Cost Ratio 


90 


$10 


$4,500 


0.027 


90 


$15 


$6,750 


0.040 


90 


$20 


$9,000 


0.053 


225 


$10 


$11,250 


0.066 


225 


$15 


$16,875 


0.099 


225 


$20 


$22,500 


0.133 



In addition to the savings from ridership, fare and invoicing, a transit system would need to save 
anywhere from $29,443 to $33,043 per year in other operational costs to achieve a benefit/cost 
ratio of 1 .0 or higher. 

Notes 

As with the computer-aided scheduling and dispatching software option, this option with in- 
vehicle technology would be most appropriate for systems with six or more vehicles. A system 
similar to Billings MET Special Transit would require only a 5 percent decrease in service miles 
or hours to benefit from a computer-aided scheduling and dispatching software system with in- 
vehicle technology. 

Total versus Local Dollars 

In addition to looking at the total value of the benefits and costs, it is also possible to look at the 
benefit/cost analysis based on "local dollars." Due to the funding of transit systems (FTA 
Section 5311 and 5307 systems), capital projects receive a high amount of Federal match, and 
operational match is typically 50-60 percent of costs (depending on certain factors). Therefore, a 
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transit system may pay 14-20 percent of the cost of obtaining ACR technologies, but would 
accrue benefits at 50-60 percent of the annual savings. Viewing the benefit/cost ratio in terms of 
"local dollars" would alter the ratios. The previous sections analysis (Table 7, Table 8, and 
Table 9), are revised herein, based on the local share to purchase the technologies of 20 percent, 
and benefits gained at 50 percent (which would be considered a "worst case" from a local 
funding perspective). 

As shown in Table 10, if the five year cost of the software is $9,900 in local dollars ($3,900 to 
purchase and $6,000 of maintenance fees), the cost benefit ratios improve to where there would 
be a benefit/cost ratio of greater than 1.0 for a transit system that spends approximately 25 hours 
per month on ridership, fare tracking and invoicing at an employee cost of $20 per hour. 

Table 10: Benefit/Cost Analysis-Basic Software-Local Dollars 



Annual Time Savings 


Employee Rate (hourly basis) 


5-year Savings 


Benefit/Cost Ratio 


90 


$10 


$2,250 


0.227 


90 


$15 


$3,375 


0.341 


90 


$20 


$4,500 


0.455 


225 


$10 


$5,625 


0.568 


225 


$15 


$8,438 


0.852 


225 


$20 


$11,250 


1.136 



Table 1 1 shows that even when analyzing the benefit/cost ratio of computer-aided scheduling 
and dispatching (CASD) software, a transit provider would need to save additional operational 
dollars to achieve a benefit/cost ratio of 1.0 or higher. 

Table 11: Benefit/Cost Analysis-CASD Software-Local Dollars 



Annual Time Savings 


Employee Rate (hourly basis) 


5-year Savings 


Benefit/Cost Ratio 


90 


$10 


$2,250 


0.058 


90 


$15 


$3,375 


0.087 


90 


$20 


$4,500 


0.117 


225 


$10 


$5,625 


0.146 


225 


$15 


$8,438 


0.219 


225 


$20 


$11,250 


0.291 



With the CASD software, the five-year total cost would be $38,600 ($16,600 for the software 
and computers, and $22,000 for the annual maintenance fees). As discussed herein, and 
highlighted in Appendix D, transit systems that use CASD software typically do reduce 
operational costs based on annual vehicle hours or vehicle miles. 

The benefit/cost analysis for CASD software and in-vehicle technologies in "local dollars" is 
shown in Table 12. 
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Table 12: Benefit/Cost Analysis-CASD Software & In-vehicle Techno 


logy-Local Dollars 


Annual Time Savings 


Employee Rate (hourly basis) 


5-year Savings 


Benefit/Cost Ratio 


90 


$10 


$2,250 


0.048 


90 


$15 


$3,375 


0.072 


90 


$20 


$4,500 


0.095 


225 


$10 


$5,625 


0.119 


225 


$15 


$8,438 


0.179 


225 


$20 


$11,250 


0.239 



The five-year local cost for the analysis in Table 12 is $47,143 ($16,000 for software, $600 for 
computers, $6,130 for the mobile data computers, $2,413 for the additional hardware and 
software, and $22,000 for the maintenance fee). As with the CASD-only analysis, a transit 
provider would have to obtain additional savings in costs to have a benefit/cost ratio of 1.0 or 
higher if using a combination of CASD software and in-vehicle technologies. As has been 
shown in national literature and in the Billings MET Report (Appendix D), additional savings are 
possible based on the operating characteristics of each provider. 

Benefit/Cost Summary 

As noted in this section, the benefit/cost analyses herein use averages of the expected costs, and a 
range of benefits to determine the ratios. A transit system that spends at least 45 hours per 
month, paying someone at least $15 per hour, would be very near a benefit/cost ratio of 1.0 
(using total benefit cost dollars). Analyzing "local dollars", a system spending 25 hours per 
month at a rate of $20 per hour, would have a benefit/cost ratio of 1.0 

The benefit/cost analysis could be modified based on specific (detailed) pricing of software that 
may be lower than indicated herein, based on the specifications of the software, and whether or 
not the price would be lower for a statewide purchase. Further, there may be some additional 
communications costs, if the software was Internet based, and transportation providers needed an 
Internet service that may require a cable or satellite based connection. 

The authors realize that many small transit systems struggle to find enough local match to 
provide the appropriate level of service in their community. The purpose of the benefit/cost 
analysis is to show the potential benefits received, either on a total or local basis, rather than to 
discuss how local match monies may be obtained. 

Based on the information from the analysis, the majority of transportation providers in Montana 
would likely benefit from a basic rider/customer software system. This system may be enhanced 
with services/technologies identified in the One Stop Shop project. No matter which 
technologies may ultimately be selected if the Montana Department of Transportation moves 
forward with a related project, there will need to be a plan in place that will minimize the risks 
involved with implementing the technologies, and maximize the benefits to the transit providers 
and other agencies. The following section discusses the issues surrounding the implementation of 
automated cost recovery and related technologies. 
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IMPLEMENTATION PLAN 

A technology with a promising benefit/cost ratio may not deliver what it promises if it is not 
implemented correctly, or as scheduled. At the time this document was written, there was a 
possibility that the primary vendor in the Puget Sound technology program discussed in previous 
sections will declare bankruptcy and cease to exist. In another example. South Carolina's Virtual 
Transit Enterprise suffered from the lack of a project manager for nearly one year after the 
project began in February 1996. 

The implementation plan must be part of an overall business strategy. Clearly defined project 
and performance goals are the first step. The plan depends on quality evaluations, manageable 
funding strategies and effective procurement. Once those are agreed on, the project becomes 
dependent on project management, training and implementation. 

Implementation Plan Steps 

1. Identify potential partnerships and interest areas in the state or region. 

2. Develop an informal network of interested parties. 

3. Develop business goals, requirements, success measures and outcomes. 

4. Identify areas of mutual gain and clearly spell them out for funding partners. 

5. Clearly identify management and staff requirements and responsibilities. 

6. Define system requirements based on user needs. 

7. Define general and specific scope of program. 

8. Identify test case project. 

9. Develop base requirements for demonstration. 

10. Solicit industry feedback. 

11. Issue cooperative RFP. 

12. Install, test and evaluate. 

13. Feed experience and lessons learned into final procurement decisions. 

A vision and goal for the implementation of any automated cost recovery project must be 
developed, whether the project will be implemented on a local, regional, or statewide basis. As it 
has been famously said, "If you don't know where you are going, how will you know when you 
get there?" In addition to the automated cost recovery project, there is a research project 
investigating the feasibility of a one-stop shop in Montana. The one-stop shop would likely 
provide public and specialized transportation clients a "single point of access" for information 
about transportation services. As indicated by the CARTS project in Texas, many of the 
technologies implemented work together to not only provide information to the transit system, 
but can be used to provide one-stop shop capabilities to the customers/riders. Therefore, it is 
recommended that MDT integrate the information from both this and the One Stop Shop report 
and investigate how the reviewed technologies may work together in one comprehensive system. 
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The first step in planning for implementation of automated cost recovery technologies would be 
to hold a meeting, or series of meetings, between MDT and transit agencies to determine the 
interest in implementing automated cost recovery and related technologies. Partner agencies, 
such as DPHHS, should be included in the discussions, as they fund transportation services, and 
are likely to benefit from the data obtained by ACR and related technologies, especially if 
implemented on a regional or statewide basis. 

The meetings would help define the information required in Steps 1 through 4 noted above. 
These steps would help all agencies/organizations involved define the benefits and costs they 
may realize as the technologies are implemented, and help define what is going to be required of 
each agency. As noted in the benefit/cost analysis section, the benefit/cost ratio changes 
depending upon whether the total costs or local costs are being examined. Further, agencies such 
as MDT and DPHHS may examine the value of near real-time information, and may provide 
funding for implementing technologies. 

Once a vision and partnerships are discussed, then it is important to detail the responsibilities of 
each agency/organization and person (Step 5). This may be as simple as transit agencies sending 
staff to training sessions to learn about new software, or it may be more complicated, as agencies 
may have staff members create a Request for Proposals for the technologies, and participate in 
the selection process. During this step, an overall project manager, or "champion," will be 
identified who will keep the project moving forward and on track. 

After the roles and responsibilities have been defined, the more detailed work of determining the 
system requirements (Step 6) and scope of the program (Step 7) begin. Which technologies may 
be implemented, and the process for implementation, will be determined at this time. The 
technologies to be implemented should follow the applicable architecture for intelligent 
transportation systems (ITS) systems that is in place with MDT. ITS architecture provides the 
framework for how systems are deployed, addressing issues such as how the various 
technologies communicate with each other, how older or "legacy" systems may be integrated, 
etc. 

It may be determined that one or several sites may be selected for implementation (Step 8), or 
that it is necessary to implement the system on a statewide basis. Also, the order in which 
technologies may be implemented will be determined at this time. For example, new software 
may be implemented, with automatic vehicle location technologies added six months after the 
software is operational. 

The base requirements for a demonstration (Step 9) will define what is expected of the 
agencies/organizations that will take part in implementing the new technologies. For example, it 
may be necessary that the transit systems guarantee they will utilize the technologies (sometimes 
computers sit in the corner of an office gathering dust), that they will update information and/or 
send reports on a weekly or monthly basis, etc. This will also require that the participating 
agencies/organizations keep track of how their business model changes after the implementation 
of the technologies. If, for example, it is anticipated that the new software will reduce ridership 
tracking and reporting times by 75 percent, participating agencies will need to track the amount 
of time employees spend on those tasks. 

Base requirements may also include whether the training was completed on-time, and issues with 
the installation and maintenance of the technologies. The evaluation plan must be developed 
before the technologies are implemented, so any "before" data can be collected. 
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After it is determined who would participate in the initial trial or test program, it is a good idea to 
talk to some people in the industry (such as vendors) to solicit their feedback on the plan (Step 
10). During this time, it is important to talk in general terms, and the vendors need to be assured 
that their participation in the general discussions will not preclude them from bidding on the 
project. It is also important during this time to make sure that the specifications of the project are 
not modified to give one vendor an advantage over another, although in some instances a sole- 
source bid may be appropriate. This step can be viewed as a "sanity check" to make sure that 
there are not parts of the implementation plan that cannot be met by the industry. 

Once there is general agreement with the plan, the next step (Step 1 1) is to issue the Request for 
Proposals (RFP). Depending upon the specifics of the project, the RFP may be issued by a state 
agency (such as MDT, DPHHS, etc.) or the RFP may be issued by a specific transit agency. No 
matter who issues the RFP, it must follow all applicable rules for selecting a vendor. It is also 
important that the RFP follows the specifications that were developed earlier in the process. In 
addition, if more than one technology is going to be implemented, it is very important that one 
vendor be designated as the "systems integrator." 

Unfortunately, when multiple technologies are being implemented, it can become easy for 
vendors to point fingers at the other vendors over why a certain system is not working. It is 
important, then, to have one vendor responsible for making the system work so the 
agency/organization implementing the technologies is not put in the middle of an argument over 
whose system is or isn't working. 

Implementation will begin after a vendor has been selected through the RFP process (Step 12). 
The proposals from the vendors should include a timeline for installing the technologies and 
providing the necessary training. It is important to track how well the vendors perform during the 
installation process, as this will be one factor in determining whether or not the technologies 
should be implemented on a wider basis. During this step, a part of the implementation process 
will be to test the technologies to find out whether, for instance, the mobile devices can talk to 
the software, or does the software function as advertised (i.e., does the database track the 
necessary information and does it produce the necessary reports, etc.). Once the technologies 
have been implemented and tested, the evaluation phase begins. 

The evaluation phase requires consideration of numerous factors, including how the RFP process 
worked, if the implementation and training phase went according to plan, and, ultimately, did the 
technologies deliver based on the anticipated benefits. To determine the value of the benefits, the 
evaluation should be conducted at least six months after the implementation of the technologies. 
This time should allow employees to become familiar with the new technologies, and be able to 
use them to their maximum extent. 

It is important to include employees, and others who will ultimately use the technologies, in all 
phases of the process as their buy-in is critical. Technology programs can fail when employees 
decide that the old ways work better, and decide not to use the new technologies, or not use them 
to their full capabilities. The input from the people using the technologies will be critical in 
determining the value of the technologies, and capturing the lessons learned from the process 
(Step 13). 

After the implementation phase, and once the evaluation has been conducted, a brief write-up 
should be done detailing what has been learned and what may be done differently as the 
technologies are expanded to a regional or statewide basis. As Montana can learn from 
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technology projects conducted elsewhere in the United States, and even elsewhere in the world, 
it is important to capture the lessons learned to provide updated information to other states, or to 
improve the processes within Montana. 

As part of this project, the WTI team has been able to review lessons learned from evaluations of 
other projects that should help the Montana Department of Transportation and/or partner 
agencies as they determine whether or not to move forward with implementing automated cost 
recovery and/or related technologies. 

Many lessons were learned from South Carolina's experience with the development and 
implementation of the VTE. They should serve as guidance not only for other states and 
organizations starting a similar system in their own areas, but also for SCDOT as it continues 
with the remaining development tasks. These lessons (Schwenk 2005) are: 



• 



• 



Strong, committed and consistent project management and leadership are perhaps the 
most important elements in a project like VTE that involves a large and diverse group 
of participants, complex interactions among many technical components, and a 
prolonged development period. This kind of leadership throughout the duration of the 
VTE project might have prevented: 

o The decision to terminate the original contractor, SCRA, without a backup plan, 
stopping the momentum of the project cold in its early stages, 

o Lack of progress in other areas of the VTE project during the time when there 
was a protest over the award of the scheduling and dispatching software (a protest 
by a vendor that wasn't awarded the contract), 

o Absence of a project manager for over one year, 

o The need to extend the project duration to more than twice the time originally 
planned, and 

o Participant attrition, some forgetting about the project altogether and not realizing 
which components it included. 

The importance of conducting thorough requirements analyses and following what is 
learned cannot be stressed enough. Problems with requirements definitions surfaced 
periodically throughout the VTE project: 

o The four-point approach agreed to in Phase I, based on thorough analysis of the 
technology needs of public providers and SCDOT, did not include vehicle 
maintenance software, yet it was the first application SCDOT gave to the public 
providers in Phase II. Only two of the public providers ever used it. 

o RouteMatch conducted detailed requirements analysis of each public provider 
prior to the Go-Live week. Nevertheless the need for the particular data required 
for Department of Health and Human Services (DHHS) billing was not realized 
until the public providers began actually using the system. RouteMatch had to 
develop several new reports for the public providers and it took at least one 
public provider over a year to work out all the reporting problems. 
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o A VTE web site could have been an effective way to instill the sense of 
belonging to a "VTE community" in the public providers and gone a long way to 
developing the "virtual enterprise" identity. SCRA hosted a VTE web site during 
Phase I, but discontinued it after the end of its contract. As one of the more 
straightforward elements of the VTE project to develop and with the required 
infrastructure in place (computers with Internet access), the VTE web site should 
have been one of the first things SCDOT implemented. Public providers could 
have used it as a focal point for information on VTE and communication with 
other participants. 

• It would have been better first to approach the public providers with the more 
straightforward elements of VTE to build their enthusiasm and confidence in their 
capabilities and the VTE Project, and then introduce the more complicated 
applications to them, conditional on the success of the earlier ones. 

• Presenting a thoroughly tested and debugged system to users creates a favorable first 
impression and positive attitude toward the product. SCDOT tested its electronic 
invoicing system on a few public providers before rolling it out to the rest, with few 
resulting glitches. On the other hand, the RouteMatch system, a much more complex 
system, was rolled out to all public providers at once. Problems encountered, even 
though some were relatively minor in nature, took a long time to resolve, with the 
result that many public providers developed a negative attitude toward the system, 
and decided not to use it. 

• During the training sessions, RouteMatch discovered that the training is more 
successful when the classes are as homogeneous as possible regarding trainee 
experience with technology, and agency size and S&D needs. Group training that 
combined several agencies at a time did not address the specific needs of the 
attendees to the degree needed, and RouteMatch had to spend significant time on 
training during the Go-Live weeks at each site to insure the users could operate the 
software properly. 

• The lack of digitized road networks that include customer addresses in some rural 
areas presented an obstacle to using the RouteMatch system in those areas. These 
networks are necessary for the route planner feature of RouteMatch to determine 
where the customers live and how to route vehicles for pick-ups. This discouraged 
some public providers from using the RouteMatch system. 

While there will still be lessons to learn from the South Carolina project, there are also lessons 
being learned by CARTS in Texas. As noted earlier, those lessons (Hosen 2007) include: 

• Walk, Don't Run-Implement one technology at a time, master it, then take the next 
step. Take your time! 

• A Solution In Search Of A Problem-Have a vision and goals. What do you want to 
accomplish with this technology? What are your technology goals? 

• Purchase For The Future, Not The Present-Think five to ten years into the future and 
ensure that your software will work with any new technologies that may be available. 
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• Demonstrations Do Not Really Count-Demos are nice, but you must see the 
technology working in the real world before you purchase. 

• Seek Out The Best Communications Option-In CARTS case a local power authority 
was bringing a state-of-the-art system on line. 

• It's Still The Staff-Success depends on staff willingness and ITS capabilities. The 
best technology requires willing and able staff to maximize performance. 

It is important that Montana review these lessons learned as it decides whether or not to move 
forward with implementing any automated cost recovery or related technologies. The steps 
herein are general, but this is based on the fact that one (or more) specific technologies have not 
been identified for implementation, even though basic rider/customer management software 
appears promising. 

The next logical step in possible implementation would be to take the information from this 
report, and combine it with the information from the One Stop Shop report, and involve 
stakeholders (transportation providers and agencies such as DPHHS) and develop a vision for 
transit technologies in Montana. The following section highlights these recommendations, based 
on the lessons learned and other information obtained through the research conducted as part of 
this project. 
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RECOMMENDATIONS 

The purpose of this report was to study the feasibility of implementing automated cost recovery 
technologies in transportation (transit) systems in Montana. Based on the information gathered 
through this project, this report recommends the following steps be taken: 

• Develop a program plan (vision and goals) that describes the desired outcome of 
implementing transit technologies in Montana. 

• Identify the steps required to accomplish the goals. 

• Procure a high-value rider/customer data management system (based on benefit/cost 
analysis). 

• Develop a pilot program for additional technologies (such as in-vehicle technologies) 
that would provide additional benefits to transit operators. 

• Develop a one-stop center that would leverage technologies implemented to support 
transportation (transit) providers, and would provide a "one-call, one-website" portal 
for customers and clients. 

The first recommendation is to develop a vision (goals) for what technologies could or should be 
implemented within transit systems in Montana. This first step would require that the Montana 
Department of Transportation hold a meeting or series of meetings with transit providers and 
"partner agencies" such as DPHHS, to determine the needs of the transit community, from both 
an operations/management standpoint, and from a customer standpoint. Once the vision and 
general goals are agreed to, the next step would be to develop a timeline (or roadmap) for 
accomplishing the goals. This step would require combining the information in this report along 
with information from the One Stop Shop project. 

This second step would identify which technologies should be implemented and in what order. 
Each technology implemented should be on the basis of the larger system/goal. For example, it 
would not make sense to use a proprietary automatic vehicle location (AVL) system that would 
not be able to communicate with a website that would be used to let customers/riders see the 
locations of the various transit vehicles. It is also important to try and procure systems that can 
be upgraded, based on newer technologies and/or communications systems. 

It appears that the majority of transit systems in Montana would benefit from a basic 
rider/customer data management system. This system should be able to support the basic 
functions of a small demand-responsive system, yet be able to expand to meet the needs of a 
larger system. The software should probably be capable of computer-aided scheduling and 
dispatching functions for the largest transit providers in the state, and be able to interface with in- 
vehicle technologies such as mobile data computers. If there is not one software available to 
meet all these needs, then two software systems that could communicate with each other would 
be the next best option. 

During the process, MDT will need to decide whether it wants to initially implement 
technologies with one or more test sites, and then expand the technologies, or if it wants to bring 
all providers on-line at the same time. Pilot program sites may also be selected for additional or 
enhanced technologies in order to study the benefits they provide to the transit providers, 
customers/riders, and state agencies. During the implementation of any technologies, it is 
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important to make note of how the various processes worked, from the RFP process, to the 
implementation and training of the technologies, so that if the systems are expanded, the lessons 
learned can be used to improve the process. 

It is recommended that the technology systems put in place be implemented with the overall goal 
of creating a one-stop shop for transit services in Montana. This does not need to be a 
complicated process, but while the various components/technologies are being planned and/or 
implemented, it is important to keep focused on the interoperability of the components, with the 
goal of eventually implementing a one-stop shop. This recommendation is made with the 
understanding that there is a separate research project being conducted in Montana related to the 
one-stop shop concept. 
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APPENDIX A: SURVEY 

The following survey was sent to 73 public and specialized transportation providers in Montana. 
A total of 34 responses were received. 
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Automated Cost Recovery - A Feasibility Study 
Organizational Survey 

This survey is being conducted by the Western Transportation Institute (MSU-Bozeman) to 
determine if it is feasible to implement electronic methods to gather ridership and fare/funding 
information from individuals using public and specialized transportation services within 
Montana. The information you provide about your organization will help with this effort. 



Agency: 



Address: 



City, Zip: 



Contact Person (Name): 



Phone Number: 



Fax Number: 



E-mail: 



Please answer the following questions about your organization. 

Organizational Characteristics 

1. Does your organization collect fares (payment) from any individual who rides your 
vehicles? 

Yes No 



If yes, please describe how your organization collect fares (i.e, the driver collects a cash 
payment, riders have passes or punch cards, etc.). 



2. Does your organization collect ridership data? Yes No 

If yes, who has responsibility (driver, dispatcher or other) for counting ridership, and 
how do they do it (memory, count sheets, etc.)? 



3. How does your organization define a "ride" (i.e., round trip, one-way trip, or other)? 
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4. What is the approximate total number of customers you have of each type noted below, 
and what is the approximate number of monthly rides you provide for each customer type 
noted? 



Customer Type 


Total Number 


Monthly Ridership 


Active (currently riding) 






General Public 






Senior Citizens 






Persons with Disabilities 







5. Approximately how many new customers (not existing customers) do you add to your 
service each month? 



6. What is the total number of vehicles operated by your organization? 



What is the number of vehicles (for carrying passengers) operated by your 
organization? 

7. Do you have passengers whose rides may be paid for by a variety of programs or 
sources? If so, please indicate the maximum number of different sources or programs 
that may pay for one customer's rides. 

8. In addition to paying for rides on public or specialized transportation services, does your 
organization also pay for rides using vouchers, or paying for transportation provided by 
taxis or other sources (such as paying for family members to transport an individual)? If 
so, please describe these various methods/modes your organization uses for 
transportation services. 

Reporting Requirements 

9. What information, if any, pertaining to ridership and fares do you report to any other 
organization? 

10. How does your organization collect and report information pertaining to ridership and 
fares? 

1 1 . Does your organization have any Issues and/or challenges with the current system you 
are using? If so, what are the issues? 

12. Do you have any suggestions for improving the data collection and/or reporting process? 
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Organizational Business Practices 

13. If your organization collects ridership and/or fare information, how does that 
data/information move from the vehicles into the office (i.e., tally sheets, electronic data 
transfer, etc.)? 

14. If your organization reports data to other agencies/organizations, how do you do that (i.e., 
send a hard copy of the report, e-mail the data, fill in an on-line form, etc.)? 

15. If your organization invoices another agency/organization for rides, how do you do that 
(i.e., send a hard copy of the invoice, e-mail the invoice, fill in an on-line form, etc.)? 

Organizational Use Of Technology 

16. Does your organization have fare boxes in any of its vehicles it uses for passenger 
transportation? If yes, does your organization use the fare box to track ridership? 

17. Does your organization have any other technology on the vehicles it uses for passenger 
transportation such as automated passenger counters, automatic vehicle location systems, 
etc.? If so, please describe the technology or technologies. 

18. When your organization tracks ridership, does it use spreadsheets or other computerized, 
electronic methods for tracking ridership? If so, please explain the methods (systems) 
used. 

19. Describe any other systems or technologies your organization uses in the process of 
carrying passengers, including tracking expenses, invoicing, reporting, etc. 
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APPENDIX B: SURVEY RESULTS 

The specific answers to each question of the survey are highlighted in this Appendix. The 
number shown for each answer corresponds to the organization that completed the survey, for 
tracking and verification purposes. Cumulative totals are provided for applicable questions for 
the purposes of basic analysis. 



Question 1. 

Does your organization collect fares (payment) from any individual who rides your 
vehicles? yes no 

If yes, please describe how your organization collect fares (i.e., the driver collects a cash 
payment, riders have passes or punch cards, etc.). 

Yes = 22 (65%); No = 12 (35%) 

1. Yes, Driver collects fares in fare box, fare boxes also accept period passes, stored ride 
passes, and designated pass program passes. 

2. Yes, Fare box, passes and punch cards. 

3. Yes, cash payments in fare box; sell punch cards and monthly passes. 

4. Yes, driver collects punch cards. 

5. Yes, driver collects, riders have passes. 

6. Yes, driver collects punch cards. 

7. Yes, driver collects cash; riders purchase passes and punch cards. 

8. No. 

9. No. 

10. Yes, driver collects cash; riders purchase passes and punch cards. 

11. No. 

12. Yes, driver collects cash or a check; riders purchase passes and punch cards. 

13. Yes, we provide transportation to folks with D.D.-they do not have to pay just one-two 
days a week they pay cash or use a voucher. 

14. Yes, driver collects, riders have passes. 

15. Yes, the driver collects. 

16. Yes, the drive collects a cash payment, suggested fare donations. 

17. No. 

18. Yes, driver collects cash; riders purchase passes and punch cards. 

19. no, 

20. Yes, driver collects a cash payment; riders purchase passes and punch cards. 

21. No. 

22. No. 

23. No. 

24. No. 

25. Yes, the driver collects a cash donation. 

26. No. 

27. Yes, the driver collects contributions. 

28. No. 

29. no. donation only 
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30. yes, driver; collects a cash fare 

3 1 . yes, driver collects or rider purchase ticket 

32. yes & no, on a volunteer basis- we have a suggested donation only- no one is required to 
pay for a ride 

33. yes, we collect fares only if we provide rides for the community health center people 
who live outside the city limits or under 55yrs old. Otherwise it's a free service. 

34. yes, a suggested donation of $1.00 per ride 

Question 2. 

Does your organization collect ridership data? yes no 

If yes, who has the responsibility (driver, dispatcher or other) for counting rider ship, and 
how do they do it (memory, count sheets, etc.)? 

Yes = 33 (97%); No = 1 (3%) 

1. Yes, Drivers record ridership through fare box. 

2. Yes, the driver collects there names and does it everyday the bus runs. 

3. Yes, the driver keeps a daily count sheet with date, time, and where they are going. 

4. Yes, driver, count sheets. 

5. Yes, driver monthly logs. 

6. Yes, driver, fill out log sheets daily. 

7. Yes, driver; count sheets. 

8. Yes, drivers utilize passenger logs to count ridership. 

9. Yes, driver; log sheets. 

10. yes, 

1 1 . Yes, driver; datasheet. 

12. yes, 

13. No. 

14. Yes, driver; datasheets. 

15. Yes, count sheets. 

16. Yes, driver; daily rider records; compiled by head driver monthly. 

17. Yes, driver; count sheets 

18. Yes, at the end of the month, the transit, manager counts up the # of rides and the records 
the information along w/ monthly fare amounts on a computer spread sheet. 

19. Yes 

20. Yes, Driver; count sheets. 

21. Yes, transportation sheets are put in the bus every morning. 

22. Yes, Dispatcher computer count sheets. 

23. Yes, Driver; count sheets. 

24. Yes, Riders sign a sheet and check. 

25. Yes, Transportation manager/Driver; count sheets. 

26. Yes, excel spread sheets kept updated by coordinator. 

27. Yes, Driver and dispatcher; collect data and use count sheets. 

28. Yes, count sheets. 

29. Yes, Driver writes out info and dispatcher count up info. 

30. yes, dispatcher/ computer 
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3 1 . Yes, Driver; collects data and records it on a daily trip sheet. 

32. Yes, Driver; count sheets. 

33. Yes, Driver; count sheets. Monthly computer spreadsheet 

34. Yes, Driver; mechanical counter units. 

Question 3. 

How does your organization define a "ride" (i.e. round trip, one-way trip, or other)? 
One way trip = 26 (76%); Round trip = 8 (24%) 

1 . one way trip 

2. one way trip 

3. one way trip 

4. Round trip one way is an option. 

5. Anytime a person re-enters the bus to go to another destination. 

6. one way trip 

7. Ride = each time passenger boards the bus. 

8. one-way trip 

9. one way trip 

10. round trip 

1 1 . one way trip 

12. one way trip 

13. one way trip 

14. one way trip 

15. one way trip 

16. one way trip 

17. one way trip 

18. round trip 

19. one way trip 

20. round trip 

21. round trip 

22. one way trip 

23. one way trip 

24. one way trip 

25. round trip 

26. one way trip 

27. round trip 

28. one way trip 

29. one way trip 

30. one way trip 

31. each disembarking is considered a ride 

32. one way trip 

33. one way trip 

34. round trip 
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Question 4. 

What is the approximate total number of customers you have of each type noted below, and 
what is the approximate number of monthly rides you provide for each customer type 
noted? 





Ac 
(current 


tive 

y riding) 


General Public 


Senior Citizens 


Persons with 
Disabilities 


Survey 


Total 
Number 


Monthly 
Ridership 


Total 
Number 


Monthly 
Ridership 


Total 
Number 


Monthly 
Ridership 


Total 
Number 


Monthly 
Ridership 


1 


Unknown 


Unknown 


Unknown 


50,035 


Unknown 


11,005 


Unknown 


Combined 
w/Seniors 


2 


Unknown 


Unknown 


176,000 


Unknown 


176,000 


Unknown 


90,700 


Unknown 


3 




65,536 




43,933 




4,114 




17,489 


4 


8 


5 


3 


2 


5 


3 








5 


















6 


616 








562 


1,128 


54 


732 


7 


45 


3,500 


21 


1,610 


14 


1,085 


10 


805 


8 














6,079 


2,026 


9 


45 


900 






45 


900 


2 


10 


10 


















11 














3,600 


300 


12 


35 


60 








35 


60 


2 




13 






10 


? 






2,000 


38 


14 


176 




56 




49 




68 




15 










4 


72 


1 


4 


16 








30 




131 




90 


17 












734 




Combined 
w/seniors 


18 






50 


100 


200 


600 


60 


1,500 


19 














70 


3,150 


20 








402 




1647 




721 


21 


25 




4 




25 




2 




22 


3 


2 






18 


5 


9 


5 


23 


315 


4,000 


100 




315 








24 














2,952 


2,952 


25 


8 


8 


3 


3 


8 


8 


5 


5 


26 












Varies 




Varies 


27 




3,500 




30 




1,400 




2,026 


28 














38 




29 


Varies 


Varies 


Varies 


Varies 


Varies 


Varies 


Varies 


Varies 


30 


4 


48 






4 


48 


2 


24 


31 






5 


10 


40 


200 


30 


250 


32 


30 


15 






28 


15 


2 


15 


33 




4 









237 




18 


34 










Varies 


141 
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Question 5. 

Approximately how many new customers (not existing customers) do you add to your 
service each month? 

Not Available = 9 (27%); Varies = 2 (6%); = 4 (12%); 1 = 4 (14%); 1-2 = 3 (9%); 
3 to 5 = 8 (24%); 6 or more = 3 (9%) 



1. 


not available 


2. 


not available 


3. 


varies 


4. 


1 


5. 


5 


6. 


10 


7. 


3 


8. 


not available 


9. 


not available 


10. 


3 


11. 


15 


12. 


2-5 


13. 


not available 


14. 


not available 


15. 


varies 


16. 


5 


17. 


not available 


18. 


5 


19. 


1 


20. 


5-10 


21. 





22. 





23. 


4 


24. 


1 


25. 


1 


26. 


not available 


27. 


2-3 


28. 





29. 


not available 


30. 





31. 


under5 


32. 


1-2 


33. 


1-2 


34. 


2 
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Question 6. 

What is the total # of vehicles operated by your organization? 

What is the # of vehicles (for carrying passengers) operated by your organization? 

Total Vehicles = 268 (Avg. 8 per agency); Passenger Vehicles = 228 (Avg. 7 per agency) 

1. 31,26 

2. 34, 20 fixed route and 9 Para transit 

3. 45,40 

4. 1,1 

5. 5,4 

6. 9,9 

7. 7,7 

8. 10,10 

9. 3,3 

10. 2, 3 on daily basis 
11.2,2 

12. 1,1 

13. 8,6 

14. 4,4 

15. 1,1 

16. 2,2 

17. 12,2 

18. 9,7 

19. 16,15 

20. 9,9 

21. 1,1 

22. 4,4 

23. 24,4 

24. 16,15 

25. 1,1 

26. 3,2 

27. 6,6 

28. 7,6 

29. 1,1 

30. 1,1 
31.2,2 

32. 1,1 

33. 1,1 

34. 2,2 
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Question 7. 

Do you have passengers whose rides may be paid for by a variety of programs or sources? 

If so, please indicate the maximum number of different sources or programs that may pay 
for one customer's rides. 

Yes = 12 (35%); No = 8 (24%); Not AppHcable = 14 (41%) 

1 . Yes, unknown 

2. unknown 

3. fixed route-None Para transit works with 4 agencies and continues to look at and 
coordinate with other agencies. 

4. n/a 

5. n/a 

6. yes-3 

7. n/a 

8. n/a 

9. yes churches and hospital 

10. yes-3 

11. n/a 

12. n/a 

13. transportation advisory council SAFTEA-LU, & DDP 

14. no 

15. Medicaid waiver 

16. county, state, and federal funds 

17. five 
18.no 
19.no 

20. Medicaid & nursing home possibilities include VFW 

21. n/a 

22. n/a 

23. n/a 

24. n/a 

25. no cash donation 

26. n/a 

27. n/a 

28. an individuals cost plan is determined through the development disabilities program 
29.no 

30. 3 from grant 

3 1 . limited Medicaid transportation 

32. n/a 

33. no 

34. no 
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Question 8. 

In addition to paying for rides on public or specialized transportation services, does your 
organization also pay for rides using vouchers, or paying for transportation provided by 
taxis or other sources (such as family members to transport an individual uses for 
transportation services)? 

Yes = 4 (12%); No = 21 (62%); Not Applicable (or blank) = 9 (26%) 

1. No 

2. N/A 

3. No 

4. no 

5. no 

6. no 

7. N/A 

8. NO 

9. no 

10. family members can purchase a punch card 

11. bus pass 
12.no 

13. vouchers 

14. no 

15. no 

16. N/A 

17. bus vouchers 

18. No 
19.no 
20. N/A 
21.no 
22. 

23.no 
24. 

25.no 
26. none 
27.no 
28.no 
29.no 

30. N/A 

31. no 

32. N/A 

33. N/A 
34.no 
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Question 9. 

What information, if any, pertaining to ridership and fares do you report to any other 
organization? 

MDT = 23 (68%); NTD = 2 (6%);Other =1 (3%); What reported = 8 (23%) 

1 . ridership by category, by route, rides to/from specific locations(paratransit) 

2. National transit database (NTD) 

3. We provide info to the NTD and Montana Department of Transportation (MDT) 

4. MDT 

5. # of rides, # of fares 

6. # of passengers, types of riders, miles traveled, rider donations 

7. MDT 

8. # of rides, # of fares, average # of hours, #rides/day; # of rides/mile 

9. # of riders and amount of fares 

10. MDT quarterly 

1 1 . MDT cost of rider program 

12. reasons for trip and customer type 

13. total # of rides to DDP and TAC 

14. State of Montana, Blackfeet Tribe 

15. Area II agency on aging and state 

16. MDT quarterly 

17. report to HATS 

18. Riders names, monthly fare collections, and total # of rides to Sheridan County each 
month. We also report the above info along w/mileage, and expenses to MDT quarterly 

19. rides, miles 

20. MDT 

21. MDT and Madison County 

22. # of riders, miles, hours used, $ in gas all reported to MDT 

23. State of Montana 

24. # of rides, performance data, financial data to MDT 

25. We report all ridership and fare info to action for Eastern Montana monthly and to MDT 
quarterly. 

26. ridership reported to MDT 

27. MDT 

28. # of riders, miles, and financial info is reported to MDT quarterly. We also indicate as 
part of our monthly invoice for DDP whether transportation was provided. 

29. MDT 

30. # of riders, and miles driven, quarterly expenses 

31. MDT 

32. Rides provided and contributions received, ect. MDT quarterly. 

33. send monthly report to Area V Agency on Aging and quarterly report to MDT due to 
getting monies from Area V Agency on Aging and the bus being a grant bus through the 
MDT 

34. Mileage and riders reported to MDT quarterly 
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Question 10. 

How does your organization collect and report information pertaining to ridership and 
fares? 

1 . Fare boxes, fixed route, scheduling software-paratransit 

2. Drivers collect # of riders. Finance collects fare info, excel spreadsheets 

3. Data is collected from daily count sheet kept by the drivers, which is then entered into a 
computer database. We do not track fares that relate to rider groups. 

4. Data is collected from daily count sheet kept by the drivers, which is then entered into a 
computer database. The info is reported to MDT quarterly. 

5. daily trip sheet for the # of rides 

6. computer print outs 

7. manually collected and reported 

8. logs 

9. count sheets 

10. daily input from coordinator 

11. Data is collected from daily count sheet kept by the drivers. 

12. Once/month to Area V Agency Aging, quarterly to MDT. 

13. manually on count sheets 

14. Daily collection of fares per ridership. If they are not handicapped or elderly fares are 
deposited to Blackfeet tribe for transit. 

15. Yes 

16. monthly worksheet 

17. drivers collect 

18. riders name, # of rides, fares paid are collected each day in log books, which is then 
entered into a computer database and these reports are sent to Sheridan County and MDT. 

19. transportation record from drivers 

20. Drivers, dispatch, adm. Assist. 

21. rider costs, trip 

22. data info sheets 

23. #'sonly 

24. Log in vehicle record all trips (one-way) taken; vehicle logs entered into a monthly log. 
Quarterly report sent to MDT 

25. Transportation manager tallies rides from drivers reporting sheet and counts all fare. This 
is done monthly. 

26. online 

27. We keep a log of ridership and fares collected. 

28. Collected utilizing passenger logs. Reported to MDT quarterly via their website, reported 
to DDP monthly via invoice 

29. via e-mail reported to MDT 

30. Log sheets filled out by drivers 

31. Driver collects ridership info/fares. Admin assembles info into usable form. 

32. tally sheets 

33. Through daily sheets, expenditure, and revenue report from the city clerk. 

34. We track the mileage daily and report quarterly. 
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Question 11. 

Does your organization have any issues and/ or challenges with the current system you are 
using? If so, what are the issues? 

None/No/or blank = 26 (76%); Comments = 8 (24%) 

1. Difficult getting information in more detail- i.e. ridership, specific route at a time of day. 

2. human error 

3. no 

4. not so far 
5. 

6. 

7. Charging customers, driver paperwork being accurate, fares not matching reported 
amounts. 

8. no 

9. no 
10.no 
11. 
12. 

13. ok 

14. Blackfeet transit needs more vehicles for transportation also needs more drivers. Funds 
are limited. 

15. no 

16. no 
17.no 
18.no 
19.no 

20. Accurate dispatch that allows enough time, vehicles and drivers top/u when needed. 

21.no 

22.no 

23. We have to purchase our own vehicles we like to run 12-15 vehicles, not small buses. 

24. too paper oriented 
25.no 

26.no 

27.no 

28. 

29.no 

30.no 

31. need to be able to track clients/assistance more efficiently 

32.no 

33. no 

34.no 
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Question 12. 

Do you have any suggestions for improving the data collection and/or reporting process? 

No (or blank) = 30 (88%); Comments = 4 (12%) 

1. 

2. electronic collection system 

3. no 

4. no 
5. 

6. more direct online reporting 

7. smart cards 

8. no 

9. no 
10. 
11. 

12.no 
13. 

14. no 

15. no 

16. no 
17.no 
18.no 
19.no 
20.no 
21.no 
22. 

23.no 
24. 

25.no 
26.no 
27.no 
28. 

29.no 
30.no 

31. more advanced dispatch system 

32.no 

33. no 

34.no 



Western Transportation Institute Page 66 



Automated Cost Recovery: A Feasibility Study Appendix B 



Question 13. 

If your organization collects ridership and/or fare information, how does that 
data/information move from the vehicles into the office (i.e., tally sheets, electronic data 
transfer, etc.)? 

Talley Sheets = 26 (87%); Driver = 3 (10%); Electronically = 1 (3%) 



1. 


electronically transferred through fare collection system 


2. 


tally sheets 


3. 


tally sheets 


4. 


hand delivered by driver 


5. 
6. 

7. 


tally sheets 


daily rider sheets by vehicle 


8. 


tally sheets 


9. 


tally sheets 


10. 


tally sheets 


11. 




12. 


tally sheets 


13. 


tally sheets 


14. 


dispatcher, tally sheets 


15. 


tally sheets 


16. 


tally sheets 


17. 


tally sheets 


18. 


tally sheets 


19. 


tally sheets 


20. 


tally sheets 


21. 


NA 


22. 


tally sheets 


23. 


tally sheets 


24. 


tally sheets turn in weekly 


25. 


driver delivers it to the transit managers office 


26. 


tally sheets 


27. 


compiles quarterly 


28. 


tally sheets monthly 


29. 


tally sheets 


30. 


tally sheets monthly 


31. 


tally sheets 


32. 


tally sheets 


33. 


tally sheets 


34. 


tally sheets 



Western Transportation Institute Page 67 



Automated Cost Recovery: A Feasibility Study Appendix B 

Question 14. 

If your organization reports data to other agencies/organizations, how do you do that (i.e., 
send a hard copy of the report, e-mail the data, fill in an on-line form, etc.)? 

Online or e-mail=16 (47%); Hard copies=4 (12%); Electronic & Hardcopies=ll (32%); 
N/A or not classified=3 (9%). 

1 . all the above 

2. internet web site 

3. online form 

4. hard copy to MDT 

5. hard copy report 

6. hard copy, online 

7. online form mail invoices with info 

8. hard copy 

9. fill in online form, hard copy 

10. MDT quarterly 

11. N/A 

12. send a copy area V agency on aging MDT gets a computerized quarterly 

13. send hard copy 

14. email/weekly deposited fare money 

15. online report to the state 

16. online form to MDT 

17. email bus report to Sheridan county, via online to MDT 

18. email 

19. online form 

20. hard copy and online forms 

21. hard copy and email 

22. hard copy and email 

23. email the data 

24. online to MDT 

25. hard copy thru the mail and online form to MDT 

26. email 

27. email quarterly to MDT 

28. N/A 

29. email the data 

30. copy of quarterly report sent to MDT 

31. online form/ hardcopy when online unviable 

32. online form 

33. hard copy, online form 

34. email quarterly reports 
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Question 15. 

If your organization invoices another agency/organization for rides, how do you do that 
(i.e., send a hard copy of the report, e-mail data, fill in an on-Une form etc.)? 

Hard copy = 11 (32%); Online or e-mail = 2 (6%); Online & Hardcopy=l (3%); Not 
Applicable (or not classified) = 20 (59%) 

1 . hard copy and online 

2. hard copy 

3. hard copy 

4. n/a 

5. hard copy 

6. hard copy 

7. hard copy 

8. n/a 

9. monthly statements 

10. monthly billings 

11. n/a 

12. n/a 

13. hard copy 

14. n/a 

15. send a statement of the online statement 

16. n/a 

17. n/a 

18. hard copy 

19. email 

20. hard copy 

21. n/a 

22. n/a 

23. n/a 

24. n/a 

25. n/a 

26. n/a 

27. hardcopy 

28. n/a 

29. no invoices donations only 

30. n/a 

3 1 . hardcopy of invoice 

32. n/a 

33. hard copy sent 

34. n/a 
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Question 16. 

Does your organization have fare boxes in any of its vehicles it uses for passenger 
transportation? If yes, does your organization use the fare box to track ridership? 

Yes = 6 (18%); No = 24 (70%); Not AppHcable or no answer = 4 (12%) 

Note: Only one organization uses its fareboxes to track ridership. 

1 . Yes, Yes 

2. Yes, not fare box use counters 

3. yes, don't use fare box to track ridership 

4. no 

5. yes, don't use fare box to track ridership 

6. no 

7. N/A 

8. no 

9. no 
0. no 
1. 

2. no 

3. no 

4. no 

5. no 

6. yes, don't use fare box to track ridership 

7. no 

8. no 

9. no 
20.no 
21.no 

22. N/A 

23. donation only 
24.no 

25. yes, don't use fare box to track ridership 
26.no 
27.no 
28.no 
29.no 
30.no 
31. no 
32.no 
33. no 
34.no 
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Question 17. 

Does your organization have any other technology on the vehicles it uses for passenger 
transportation such as automated passenger counters, automatic vehicle location systems, 
etc.? If so, please describe the technology or technologies. 

No = 26 (76%); Not Applicable = 4 (12%); Other technologies = 4 (12%) 

1. Auto announces some vehicles are equipped for AVL but that function/equipment not 
purchased. 

2. no 

3. AVL systems on all of the Para transit vans to track vehicle location and aid in 
dispatching. 

4. driver carries a personal GPS receiver that he uses to collect data on each trip, download 
and merge with a maps program and prints out a map of each trip with all the stop-to be 
used for future route planning. 

5. no 

6. no 

7. N/A 

8. no 

9. no 
10.no 
11. no 
12.no 

13. no 

14. 2- way radio from driver to dispatcher 

15. no 

16. no 

17. no 
18.no 
19.no 
20.no 

21. N/A 

22. n/a 

23. n/a 
24.no 
25.no 
26.no 
27.no 
28.no 
29.no 
30.no 
31. no 
32.no 
33. no 
34.no 
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Question 18 

When your organization tracks ridership, does it use spreadsheets or other computerized, 
electronic methods for tracking ridership? If so, please explain the methods (system) used. 

No (or blank) = 17 (50%); Excel Spreadsheets = 16 (47%); MDT Forms = 1 (3%) 

1. spreadsheets to track ridership by day, month, and year. The spread sheet also allows 
ability to create specific reports. 

2. Excel Spread sheets 

3. Excel Spread sheets 

4. no 

5. Excel Spread sheets 

6. Excel Spread sheets 

7. Excel Spread sheets 

8. Excel Spread sheets 

9. Excel Spread sheets 
10. 

ll.no 
12. 

13. Excel Spread sheets 

14. Excel Spread sheets 

15. no 

16. no 

17. Excel Spread sheets 

18. Excel Spread sheets 

19. Excel Spread sheets 
20.no 

21.no 

22. forms from MDT 

23.no 

24. Excel Spread sheets 

25. Excel Spread sheets, driver tallies ridership 
26.no 

27.no 

28.no 

29.no 

30.no 

31. no 

32.no 

33. Excel Spread sheets 

34.no 
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Question 19 

Describe any other systems or technologies your organization uses in the process of 
carrying passengers, including tracking expenses, invoicing, reporting, etc. 

Not Applicable = 25 (73%); Quicken/QuickBooks = 4 (12%); Excel Spreadsheets = 1 (3%) 
Other = 4 (12%) 

1. n/a 

2. computer 

3. n/a 

4. n/a 

5. n/a 

6. n/a 

7. QuickBooks is used to prepare invoices and track expenses and revenue. Excel and lotus 
to prepare daily trip sheets/manifest. 

8. n/a 

9. Quicken 

10. n/a 

1 1 . Excel spreadsheets 

12. QuickBooks is used to track expenses. 

13. we are physically responsible to DDP, but now report to TAC as well all expenses, 
rider ship totals ect. 

14. Automatic chair lifts for the disabled 

15. n/a 

16. n/a 

17. n/a 

18. n/a 

19. n/a 

20. QuickBooks is used to prepare invoices and track expenses and revenue. 

21. n/a 

22. n/a 

23. n/a 

24. n/a 

25. n/a 

26. n/a 

27. n/a 

28. n/a 

29. n/a 

30. n/a 

3 1 . Accounting system utilized for paying expenses, tracking budget. Reports completed 
online after manual tracking. 

32. n/a 

33. n/a 

34. n/a 
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Follow-up question 

As noted in the document, a follow-up question was sent (via e-mail) to those who had 
responded to the initial survey. The text of the e-mail is as follows: 

First, I would like to thank you for taking the time to complete the Automated 
Cost Recovery Organizational Survey that was sent to you a few months ago. As we 
finalize the project, I realized there was one bit of information I forgot to inquire 
about in the survey. That is the reason for this follow-up e-mail. 

I need to know the amount of time your organization spends (either on a daily, 
weekly or monthly basis) tracking ridership and fares/payments on your 
transportation (transit) system. You can lump both (ridership and fares/payments) 
together, or list them separately. 

For example, you can respond: " 1 hour per day on ridership, and 1 hour per day 
on fares/payments" or you could respond, "40 hours per month on ridership and 
fares". For transportation (transit) systems with both fixed route and demand 
responsive services, I am looking for the hours you spend on both services (fixed 
route and demand response combined). 

Thank you for your response to the previous survey, and thank you for 
responding to this e-mail. 

A total of three follow-up e-mails were sent. However, only the following ten responses were 
obtained: 

1. 35 hours per month fixed route, 9 hours per month demand response. (528 hours/year) 

2. 1 hour per day, total. (250 hours/year) 

3. Drivers and dispatchers, approximately 5 hours per day. (1,250 hours/year) 

4. Drivers and dispatchers, about 2 hours per day. (500 hours/year) 

5. 1 hour per week on ridership, 1 hour per week on payments. (104 hours/year) 

6. 7 hours per month on ridership and fares. (84 hours/year) 

7. 10 hours per month, total. (120 hours/year) 

8. 10-15 hours per month. (120-180 hours/year) 

9. 2 hours per month, total. (24 hours/year) 

10. 10 hours per month, ridership and fares/payments. (120 hours/year) 

Note: for purposes of the benefit/cost analysis, it is assumed that there are a total of 250 service 
days for the transit agencies. The annualized totals (for analysis purposes) are shown after the 
response. 
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APPENDIX C: MOBILE DATA COMPUTER INFORMATION 

The following information was provided by Mentor Engineering (Calgary, Alberta, Canada). It is 
provided for informational purposes only and should not be considered an endorsement of 
Mentor Engineering. 
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MENTOR ENGINEERING'S MOBILE DATA CO 

(MDC) is an easily customized vehicle -mounted devii 
that increases the efficiency and productivity of fleet 
operations. Installed in over 9 countries and 12 ir^dustries 
worldwide, the MDC helps organizatiDns improve 
response times, decrease operating 
costs, automate data colEection, | 



GeoGuidefor 
In-Vehicle Navigation 



Two-Way Text Messaging 



Covert Microphone 
for Added Security 



CoHection 



reduce paperwork and increase 
overall customer service. 



Internal 
Taximeter 



Internal 






The MDC eliminates the need 
to purchase multiple devices internal GPS 

by incorporating numerous (Supports 

features into a single unit. 
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Built to Work 



U 



rlike consumer products such as cell phones and PDAs, the MDC is specificaEfy built 
to work in the ever-changing fleet environment. Its rugged ABS enclosure and high 
resistance to temperature and humidity fluctuations make if ideal for vehicle use. 



Efficiency 

The MDC's automatic data collection feature helps gen- 
erals a variety of reports to nwnitor an operation more 
thofou^ly, PreviouslVj drivers filled out manual logs^ 
noting pick-up and drop-ofT times, mileage, fares and 
breaks. The MDC does that work and more with the 
push of a button. The information Is then sent in real 
time to the office, saving manual re-entry time and re- 
ducing tlie possibility of hunian error. 

Scalability 

Mentor offers a complete line of wireless data prcducts 
in addition to the MOC. That means you can enhance 
your system by increasing its level of sophistication. Add 
Mentor Ranger,** our rugged, fixed-mount computer; or 
Stryder,'^ Mentor's mgged, portable tablet computer, to 
Optimize functionanty. 




Safety and Security 



The MDC offers an emergency button and optional co- 
vert microphone to increase driver and passenger safety 
If a problem ariies, tiie driver simply hits the emergency 
button, and dispatch is notified immediately With GPS, 
dispatch can instantly track the vehicle and send help 
to its precise location. 

Customizable & Flexible 

The MDC can be tailored to meet !he unique reeds of 
a business. Mentor's engineers will build specific func- 
tionality into your system so It works for you. The MDC's 
multiple inputs and outputs can interface to odometers 
and other vehicle telemetry (Jl 708). In addition, it sup- 
ports numerous peripherals for added functionality. 

Convenience 

In-vehicle financial transactions are possible with the 
MDC's built-in magnetic stripe card reader. Automatic 
credit card authorization reduces the amount of cash in 
the vehicle and provides customers a conv&nient pay- 
ment option, The MDC's built-in smart card reader allows 
for quick and easy driver and passenger identification, 



GPS Capability 



- GeoOdometer automatically calculates vehicle mile- 
age between events liice pick-ups and drop-off 

• GeoGuide points drivers in the right direction and 
keeps them on course 

• GeoZone automatically triggers an action (e.g, send 
odometer and GPS reading) when vehicles enter or 
leave zones that are pre-defined and programmed 
into the MDC 

• GeoTarget automatically tn^ers an action [e,g, pop 
up driver message) when a vehicle a rhves at, or 
departs from, a particular geo-coordinate 

' GeoSid provides drivers the opportu nity to bid on 
fares within their geographic territory 



Supported Peripherals 



■ Keyboard 

• Odometer 

- Passenger Counter 

' Electronic Fare System 

' Smart Card Reader 



■ Printer 

- LED Sign 
' Voice Annunciator 
• Bar Code Reader 
. , .And More 



Technical Specs 

• 240 x 64 transflective backSit graphical LCD display 
with adjustable contrast, scrolling capability and 
adjustable font size 

■ Keypad with adjustable backlighting, audible and 
tactile feedback 

■ Rugged ABS enclosure 

• Optional inte^rnal 16-channel GPS receiver tor 
Automatic Vehicle l_ocation (AVLJ 

■ Internal smart card reader/writer and magnetic stripe 
(e.g. credit or debit) card readef 

• Optional PCIVlCIA slot for increased data storage 
and repragramming 

■ Multiple l/Os; suppods a variety of peripherals 

■ Emergency l\ey and optional covert microphone 

■ Reld programmable: software upgrades can be 
added to the system without removing the M DC 
from the vehicle 

■ integrated public data or RF modem [optional) 

• Optional integrated taximeter 

■ Size: S. 25" X 3-5" X 2" (2 10 mm x 89 mm x 50 mm) 

Mentor Engineering liic reserves trte rightto modify these 
5pBcification5i and corriponenls without notice. 



MSMENTOR 



m. 2175-29 Bi street fJE 

CelgHFy AB Canada TIV 7HS 

Pli 403 777 3760 Fa* dOE 777 3769 

aalffi@nrantoreng.Kim www, men tore ng.K 



Cnwrght -Vi Z0D6 Mentco EnsnEa 
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Sleeker Faster Stron ger 




Sleeker, faster, stronger and smalJer, Ranger is 
ore of a handful of new-era wireless computers 
on the market. But, unlike most in its class, 
Ranger already has in-fie!d experience, seri/ing 
the EMS, fued route, demand response, taxi 
and emergency roadside service tnciListries, 
with Range r^ clients gain unproved response 
times, operational efficiencies, and driver 
safety — benefits integral ta the sophisticated 
fleet management processes Ranger supports. 



Internal Wireless 
Modem 



USB Ports 

(1 host*, 1 device) 



Audio Inputs/Outputs 



6.4" VGA TFT Backlit 
Color Display & Touchscreen 
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End-to-End Wireless Data Solution 

Whether your fleet consists of five or 5000 vehicles, Ranger is built to meet your 
performance requirements. From drivers to dispatch, Ranger helps to ensure your fieet 
is always connected by allowing access to a wide range of Windows CE appiications 
and providing developers with tools to write software customized to your operation, as weli as 
supporting third-party, industry-specific software. 



Easy Viewing 

Ttie entire Ranger unit measures little more that 8x5 
inclies, and text is clearly viewed on Ranger's full-color, 
Jiigti -resolution VGA TFT backlit touchscreen display 
{5.25x4 inches). In addition, backlight! rig ensures screen 
viewing in a variety of lighting conditions. 



At the Office 

Computer Aided Dispatch (CAD) 

With Ranger, driver schedules, forms, reports and 
other documents are generated, processed and shared 
electronically, Dispatchers can generate a driver's daily 
schedule and instantly send It to the in-vehicle computer. 

Automatic Vehicle Location (AVL) 

With AVL capabilities, Ranger empowers dispatchers 
with the ability to identify the location and status of eacii 
vehicle in their care, When a iob comes into the dispalctf 
center, dispatchers can see the whereabouts and status 
of their drivers and send the approprlale vehicle to a job. 
dramatically improving response times. 




In the Vehicle 



Onboard Navigation 

Ranger offers complete onixard navigation tools and 
supports the latKt mapping software. Using either the 
integrated or external GPS receiver, drivers can easily 
navigate to their next job with tum-by-turn prompts. 

Real-time Communication 

Papsr processes to complete jobs and disihbute work 
schedules, which can result in lost information, confusion and 
disorganization, tscomea thingofthe past. Ranger replaces 
this with convenient, real-time electronic communication 

instant Identification 

Ranger has a buiiit-in smart card reader and optional; 
magnetic stripe card swipe that offer a simple and secure 
form of driver and customer identification, and facilitate 
on-the-spot financial transactions. Both card readers are 
integrated with Ranger so clutter in the vehicle is kept to 
a minimum. 



Seamless Upgrade 

Wler^lor offers a complete line at mobile data products. 
if, for example, you are currently operating with Mentor's 
MOC and wisfi to upgrade to Ranger, Mentor can provide 
a convenient upgrade path. In addition, Mentor strives 
to make all of its products both fonA^ard and backward 
compatible. As your communication needs grow and 
change, so does your mobile computing solution, easily, eaF.yri.eii oj md6 Memoi Enuiwenng 



efficiensly and economically. Mentor will work to 
configure its products to work with those technologies 
that already esisl, reducing your costs, 

BBX and XGate 

Combine l^snger with Mentor's other mobile products 
such as BBX for expanded functionality, BBX is a 
wireless modenVAVL/telematic data collection device with 
a 16-channel GPS receiver. Or utilize Mentor's XGate 
middleware — software that connects your Ranger units and 
host application software by way of virtually any wireless 
data network for the ultimate in network versatility 

Technical Specs 

Windows CE operating system 

Intel XScale 400 MHz processor 

Memory: 512Mb of SDRAM (64MB) / 512Mb 

of FLASH (64MB) 

Size; 8.3" j; 5.5" x 1.6" 

(210nim X 140 mm x 40 mm) 

Multiple l/Os and connection ports 

6,4" VGA TFT full-color display (640 x 480) 

internal ISO 7816 smart card reader 

Microphone & stereo speakers 

Type 2 compact flash socket 

Audio inputs^outputs 

Wireless connections: 802. 1 lb capable 

Internal IG-channel GpS receiver (optional) 

integrated taximeter (optional) 



SSSMENTOR 

mm ENCrNEERFNG 



10, 2175- 29*1 SlreetNE 
Cal^iyABCamadaTlY 7HS 
Ph 403 777 3760 Fax 403 777 3769 
5alesgwento(en8.M»n wisw.n'kertofeflg.com 

All fighB hMtfirtd 
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Mentor's CE Application 

for Demand Response Transit 



^MENTOR 

^m ENCINEEHINC 

SYSTEMS THAT WORK 



A A entor Engineering has developed a demand response application to run on its Windows CE 
l V \ product line. The application takes advantage of Mentor's years of experience developing 
rr\obiie software for transit organizations, features include in-vehicle mapping and navigation, 
color-coded trip manifests, and pop-up windows for messages requiring prompt attention. 

What follows are sample screenshots from th is appi ication: 



fcj Logon 
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Mwrm 

1 1 
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Remarks: Dialysis appointment. 
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SHOW 
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Eq: AM | 


PICK 
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} 
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CQ 
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08:48 
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Trip Insertion 

Tirre: 11:00 
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Hitch Hellen 



Night Screen 



Client Fare Collection 



Trip Additions 



08:48 



Notltlratlon 

Trip Cancellation 
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DElfTE 
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APPENDIX D: BILLINGS MET ROUTEMATCH REPORT 

Following is a report that was prepared for Billings MET Transit in relation to its 
implementation of RouteMatch software in its MET Special Transit (demand response) service. 
The report highlights a cost/benefit analysis of the RouteMatch software. While it doesn't focus 
specifically on fare collection and reporting, it does discuss the ability of the software to reduce 
the number of hours (and/or miles) that vehicles travel, thus reducing the cost of providing 
transportation services. 



An Evaluation of RouteMatch Software in the 
Billings MET Special Transit System 



By 

David Kack, Research Associate 

and 

Deepu Philip, Graduate Research Assistant 

Of 

Western Transportation Institute 

College of Engineering 

Montana State University - Bozeman 



May 2, 2007 



Western Transportation Institute Page 81 



Automated Cost Recovery: A Feasibility Study Appendix D 



EXECUTIVE SUMMARY 

In 2003, MET Transit in Billings, Montana was notified that the Mobility Master software it was 
using for its MET Special Transit (MST) service would no longer be supported, and wanted to 
research alternative software solutions. MET Transit contracted with the Western Transportation 
Institute to assist in an analysis of the technology currently used in MST, MET Transit's 
paratransit operations. 

In addition to the software analysis, MST asked WTI to review the benefits of adding automatic 
vehicle location (AVL) and Mobile Data Communications (MDC). To review the benefits of 
these additional technologies, the Western Transportation Institute performed a literature review 
and incorporated those findings into a report for MET Transit [1]. 

Subsequendy, the City of Billings developed a Request for Proposals, and ultimately selected 
RouteMatch Software. Both MET Transit and RouteMatch Software were interested in 
evaluating the effect the new software would have on the system. The Western Transportation 
Institute (WTI) performed an evaluation that looked at both quantitative factors (rides per mile, 
rides per hour, on-time performance) as well as qualitative factors (surveys of the drivers and 
dispatchers). 

For the evaluation, researchers compared three months (July, August and September) in 2005 
with the same three months in 2006, roughly six months after the RouteMatch software was 
installed. They believed that it was necessary to have comparison data that would show the 
impact of the software, and decided that after six months of using the new RouteMatch software, 
the dispatchers should be proficient with the system. 

The results indicate that MET Special Transit operations were more efficient after the software 
was installed. This conclusion is based on data that the rides per mile and rides per hour were 
higher during the three-month evaluation period for 2006. However, researchers did not have 
enough data on cost parameters (fuel, insurance costs, etc.) to conduct a definitive analysis of 
whether or not the RouteMatch software had a positive benefit to cost ratio ("paid for itself). 

A break-even analysis, however, did indicate that only a slight gain in efficiency could lead to a 
positive benefit/cost ratio. The data shows that if the cost of the hardware and software is 
amortized over a five-year period, and taking into account the annual maintenance fees, MET 
Special Transit (MST) would only need to decrease mileage and/or hours by approximately three 
percent for the software to have a positive cost savings for the organization. This is a relatively 
modest gain in efficiency. As indicated within this report, these appear to be achievable goals. 

One item to note about the gains in efficiency is that during the time the RouteMatch software 
was being used, the MST dispatchers did not use the RouteMatch Scheduling Engine (RSE) 
function of the software. The RouteMatch Scheduling Engine component is the function that can 
be utilized to maximize the efficiency of the transportation (transit) service. One hypothesis of 
why MET Special Transit did not use the RSE is that MST has many contracts with various 
agencies to provide rides, and was already very efficient at grouping these rides. Therefore, a 
transportation agency that schedules more individual rides may see a greater benefit from using 
RouteMatch software, than was experienced by MET Transit. 

The analysis of pick up and drop off times indicated that slightly fewer pick ups were made 
within the 30 minute window established by MET Transit when the RouteMatch software was in 
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use (84.5 percent in 2006, versus 87.5 percent in 2005). In 2006, slightly more drop offs were 
made within 15 minutes (plus or minus) of the scheduled time (84.5 percent in 2006 versus 79.8 
percent in 2005) with the use of RouteMatch software. 

One hypothesis on the differences in the pick up and drop off times is that the RouteMatch 
software is creating a more "normal" distribution of the times, whereas when the Mobility 
Master software was being used, and the rides were being scheduled manually, the dispatchers 
may have provided extra time between origins and destinations, leading to the drop off times 
being closer to scheduled times. 

While a definitive benefit/costs analysis could not be conducted to determine if the RouteMatch 
Software paid for itself, as indicated by this review, it does appear that only a minor gain in 
efficiency is necessary for the RouteMatch software to pay for itself (reach the break-even 
point). The data herein, and previous national studies, indicated that these gains in efficiency are 
achievable. 
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INTRODUCTION 

Billings MET Special Transit (MST) is a paratransit service that operates within the Billings, 
Montana city limits. Service is available between the hours of 6:30 a.m. and 6:00 p.m. during the 
weekdays, and between 9:00 a.m. and 5:30 p.m. on Saturdays. The service is offered to persons 
who qualify as ADA Paratransit eligible. 

On average, MST provides 250 to 300 rides on a typical day. Approximately half of these rides 
are subscription rides, meaning the same rides occur at the same time each day. Currently, these 
rides are all assigned to a specific route. MST has 15 paratransit vehicles at its disposal. 
Typically, half of these are out at any particular time, and on busy days, as many as 12 vehicles 
may be in service. The number of vehicles in service is a function of the number of ride requests, 
the time of day, and the geographic location of origins and destinations. 

In order to handle ride requests, MST has two dispatchers available throughout the week 
between the hours of 7:00 a.m. and 5:00 p.m. and a third person that can dispatch as needed. In 
order to schedule a ride, an individual must call in a ride request at least 24 hours in advance. 
The individual cannot schedule a ride more than two weeks in advance. Same day ride requests 
are scheduled only if time in the current manifests permits. 

The process of receiving, scheduling and dispatching rides is a complicated process. For MST it 
was even more difficult, because the dispatcher was doing the scheduling with no support from 
the software. MST was using Mobility Master software, which was not working properly, and 
very little technical support was offered. In fact, MST learned that by the end of 2003, no more 
support would be provided for the software. 

The difficulty with manual dispatching, especially when dealing with more than three or four 
vehicles, is that the dispatcher/scheduler needs to know where the vehicles are, the current load 
of the vehicle, and whether the vehicle can handle dropping off the passengers by the required 
time. This process is typically much more efficient when dispatchers can use Computer Aided 
Scheduling and Dispatching (CASD) software. 

MET Transit contracted with the Western Transportation Institute (WTI) to conduct research to 
determine the potential benefits of Computer Aided Scheduling and Dispatching software, and 
other technologies, such as Automated Vehicle Location (AVL) and Mobile Data 
Communications (MDC). WTI presented its findings to MET Transit [1] and based on the 
information, Billings MET Transit decided to purchase a new software system for their 
paratransit service MST. 

Subsequently, MET Transit contracted with WTI to assist in writing a Request for Proposals 
(REP), which was used to select a software vendor. The REP was completed and RouteMatch 
was selected as the software vendor. RouteMatch Software is headquartered in Atlanta, Georgia, 
with seven additional offices across the U.S. and comprises a team of software engineers, 
Internet technologists, computer scientists, management information experts, database 
management professionals, and transportation consultants. RouteMatch provides solutions for 
demand responsive and fixed route systems, and partners with other vendors to provide 
additional components (applications) including AVL and MDT/MDC. More information about 
RouteMatch can be found at www.routematch.com. 
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Both MET Transit and RouteMatch were interested in knowing the impact of the new 
RouteMatch software on the operations of MET Special Transit. While research has shown 
benefits of using Computer Aided Scheduling and Dispatching software [2,3,4], and RouteMatch 
has issued case studies highlighting the benefits of their software, there are relatively few cases 
where the switch to a new software system has been independently evaluated. With the 
opportunity presented in Billings, RouteMatch contracted with the Western Transportation 
Institute to conduct an independent evaluation of the effects of its software on the Billings MET 
Special Transit (MST) system. 

The remainder of this document provides an overview of Computer Aided Scheduling and 
Dispatching software, and other related technologies; the evaluation of the RouteMatch software 
in Billings, and conclusions from the evaluation. 
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PUBLIC TRANSPORTATION TECHNOLOGIES 

MET Transit was interested in exploring three primary technologies: computer-assisted 
scheduling and dispatching software (CASD), automatic vehicle location (AVL), and mobile 
data communications (MDC) technologies. 

Technology Overview 

Advances in technology along with federal and state transportation initiatives in the United 
States over the last decade have provided an impetus for paratransit operators to invest in 
technological upgrades such as computer-assisted dispatching, automatic vehicle location and 
advanced communication technologies. Computer-assisted scheduling and dispatching (CASD) 
software has the potential to improve performance in a number of ways, including increased 
vehicle load ratios, interagency connections, interactive voice driven reservation systems and 
dramatically streamlined billing operations [2] . 

While Computer-assisted scheduling and dispatching software on its own has the potential to 
improve the efficiency of paratransit operations, many transportation providers are also adding 
AVL and MDC technologies. The now common use of global position satellite (GPS) 
technology has further increased the use of AVL/MDC technologies [3]. The AVL/MDC 
technologies interface with CASD to provide a powerful tool to increase the efficiency of a 
transportation provider. 

Software 

Computer-assisted scheduling and dispatching (CASD) software is used to assign demand- 
responsive transit customers to vehicles. The software makes recommendations, in either real- 
time or batch processing mode, on which vehicle run to place a requested trip. The software may 
use Geographic Information Systems to map the source and destination address for making 
recommendations [3]. 

Because it is difficult for a human mind to keep track of more than about three vehicles at a time, 
the CASD software is valuable in providing an initial solution. The dispatcher can then review 
the manifests (schedule) and make any changes necessary. CASD can be a powerful tool for 
increasing a transportation provider's efficiency. 

In Santa Clara County, California, a paratransit operator, OUTREACH, utilized CASD software 
and was able to reduce its number of vehicles in service from 200 to 130. Using CASD software, 
the Winston-Salem Transit Authority was able to reduce its operating cost per vehicle-mile 8.5 
% and its operating cost per passenger 2.4% [4]. 

By utilizing new CASD software, it was anticipated that MET Transit should be able to increase 
its efficiency, allowing more clients to be served for the same operational budget. When tied to 
other technologies, such as automatic vehicle location (AVL) and mobile data communications 
(MDC), it was believed that further benefits would be achieved. 
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Other Technologies 

While computer-assisted scheduling and dispatching software is a powerful tool alone, utilizing 
it in conjunction automatic vehicle location and mobile data communications expands the power 
of the software. 

Automatic vehicle location (AVL) technologies measure the real-time location of vehicles using 
onboard computers and a positioning system (such as a global positioning system) and relay this 
information to a central location (such as the dispatching office). With an AVL system, the 
dispatcher, or CASD software, knows the exact position of each paratransit vehicle and can use 
that information to assign a ride (such as a "will call" or same day request) to the nearest vehicle. 

When changes are made to the schedule, or ride requests are processed, agencies typically use a 
radio to notify drivers of the change. However, many agencies are now using mobile data 
communications to relay this information between the drivers and the dispatching center. Mobile 
data communications (MDC) are accomplished by providing a link between the dispatch center 
and the paratransit vehicle, equipped with a mobile data terminal (MDT). 

Mobile data terminals are small computer terminals in the vehicle that allow a driver to receive 
and send text and numerical data by radio signal. This communication system, when tied into an 
AVL and CASD software package, allows the dispatcher to make changes to schedules and relay 
those changes without making a radio call. Further, by monitoring the progress of the schedules, 
the CASD/AVL/MDC system can alert the dispatcher if any of the paratransit vehicles are falling 
behind schedule, and can provide recommendations for shifting rides to other vehicles. 

While each of the technologies, CASD, AVL and MDC, provide a unique advantage, the 
technologies are most effective when they are combined. It was recommended that if MET 
Transit pursues new technologies that it should invest in all three of the above noted systems. As 
of the writing of this report, MET Special Transit is using the RouteMatch software with 
Automatic Vehicle Location technology. MET Transit hopes to invest in Mobile Data 
Communications when it can secure additional funding. 
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EVALUATION 

The focus of this project was to evaluate the effect, if any, that the introduction of RouteMatch 
software had on the service provided by MET Special Transit (MST). The analysis procedure is 
summarized as follows: 

• An initial set of data was collected for the months of July, August and September in 
Year 2005, which is before the purchase and installation of the software. 

• An analysis was performed on the data so that performance measures (benchmarks) 
were established. 

• A second set of data was collected for the same three month period in 2006, which is 
approximately six months after the installation of the software. 

• A data analysis was performed on the 2006 set of data. 

• The values (two sets of data) were compared to each other to determine the effect of 
the software. 

It should be noted that during the period of this analysis that the dispatchers at MET Special 
Transit did not use the RouteMatch Scheduling Engine (RSE) that is part of the RouteMatch 
Software. RSE is typically used to optimize the schedule (manifest) for the demand-responsive 
service. One reason given for not using RouteMatch Scheduling Engine was that many of the 
rides provided for by MST are already grouped, and that using RSE would not lead to any 
significant improvements in the schedule. This is discussed in more detail later in this section. 

Performance Measures 

Demand responsive transportation systems such as MST are judged (measured) by different 
people on different parameters. Administration/management typically looks at parameters 
("measures of effectiveness" or "MOEs") such as the cost per ride, rides per hour and rides per 
mile. Dispatchers and drivers may use more subjective parameters, such as the ease of creating 
and/or driving the schedule (based on the manifest). Riders use both subjective and objective 
measures, such as the timeliness of the pick up and drop off times, as well as how long they are 
on the vehicle. 

In this project, we considered both the objective and subjective measurements. However the only 
measurement with a passenger's perspective is the timeliness of the pick up and/or drop off. All 
other measurements are based on MET Transit's perspective, including both the 
administration/management and dispatch/driver perspectives. 
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The specific measures of effectiveness used in the evaluation include: 

• Rides per mile 

Rides per hour 

Cost per ride 

Pick up time performance 

Drop off time performance 

Survey results from the dispatchers 

Survey results from the drivers 

In evaluating the RouteMatch software, an attempt has been made to account for all of the 
extraneous variables, to the maximum extent possible. This allows for a true accounting/analysis 
of the impact the software has had on MST operations. The following sections provide an 
explanation of these measures, and the results from the evaluation. 

Rides per Mile/Rides per Hour 

The rides per mile and rides per hour measures are used to determine how efficiently the service 
is being operated. An inefficient service would have very few rides per hour or rides per mile. 
Both of these factors can be influenced by the size of the area a transportation provider services. 
For example, if a provider typically travels 20-30 miles to get one rider, their rides per mile may 
be significantly lower than a provider who travels only 5-10 miles to pick up riders. 

However, by efficiently scheduling and dispatching rides, a transportation provider can "group" 
more rides on each vehicle, and be more productive with assets (vehicles and drivers). As 
previously noted, some transportation systems have been able to decrease the number of vehicles 
in service by 35 percent by being more efficient in their scheduling, primarily by using computer 
aided scheduling and dispatching software [4]. 

Table D-1 shows the rides, hours and mileage for the July-September period in 2005 and 2006 
that are used for this report. Table D-2 and Table D-3 show the differences in the rides per hour 
and rides per mile for MST, before (2005) and after (2006) the use of the RouteMatch software. 
The full data used for this comparison is shown in Appendix A. 
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Table D-1: 2005-2006 Data 






2005 


2006 


Difference 


Percentage 


Rides 


17,007 


16,097 


-910 


-5.35% 


Hours 


4,790 


4,241 


-549 


-11.46% 


Mileage 


54,742 


50,566 


-4,176 


-7.63% 



Table D-2: MST Rides per Hour 



Month 


2005 


2006 


Difference 


Percentage 


July 


3.56 


3.70 


0.14 


3.93% 


August 


3.55 


3.85 


0.30 


8.45% 


September 


3.54 


3.83 


0.29 


8.19% 


3 -month avg. 


3.55 


3.80 


0.25 


7.04% 


Table D-3: MST Rides per Mile 


Month 


2005 


2006 


Difference 


Percentage 


July 


0.31 


0.32 


0.01 


3.23% 


August 


0.31 


0.32 


0.01 


3.23% 


September 


0.31 


0.32 


0.01 


3.23% 


3 -month avg. 


0.31 


0.32 


0.01 


3.23% 



Table D-1 indicates that while fewer rides were provided during the July-September period in 
2006, the hours and mileage decreased at a greater rate during this time period. Table D-2 and 
Table D-3 highlight an increase in efficiency as the rides provided on a per mile and per hour 
basis were slightly higher when the RouteMatch software was in use. However, it is important to 
note that the Route Schedule Engine (RSE) portion of the RouteMatch software was not being 
utilized during this time. It is unclear, therefore, what caused the changes in these metrics. 

Cost per Ride 

The cost per ride is another measure of efficiency and system performance. For example, if it 
costs a transportation system $500,000 to provide paratransit service, and a total of 100,000 rides 
are provided, the cost per ride is five dollars ($5) or $500,000/100,000=$5. 

It is important to note that the cost per ride may increase, without any service changes in a 
transportation system. For example, if the paratransit system's insurance increased by $10,000 
per year, the total cost for providing the service would increase to $510,000. Based on this 
information, the cost per ride would increase to five dollars and ten cents ($5.10). Therefore, 
when the cost per ride increases (or decreases), it is always important to analyze why the change 
occurred. Unfortunately, not enough data was available to account for variables such as fuel and 
insurance costs. MET Transit acknowledged that their fuel and insurance costs had increased, but 
they could not specify by how much. Therefore, the data was not available for a cost-per-ride 
comparison based on the introduction of RouteMatch Software for MET Special Transit. 
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However, a break-even analysis was conducted to determine how much would have to be saved 
on an annual basis to make the RouteMatch Software cost effective. 

Break-Even Analysis 

MET Transit paid a total of $83,575 for the RouteMatch Software, including the hardware 
necessary to operate the software. For the purpose of this analysis, it was calculated that the 
software and hardware will have a five-year lifespan. Based on this scenario, MET Transit would 
need to save approximately $16,715 per year to reach the break-even point. However, there is a 
software maintenance fee of $11,835 per year. When this maintenance fee is included with the 
amortized purchase price, a total of $28,550 would need to be saved on an annual basis for the 
software to have a positive benefit/cost ratio. 

Based on MET Special Transit's costs of $55.22 per vehicle revenue hour, and $4.81 per mile for 
2005 (see Appendix A), MST would need to save approximately $1.83 per hour, or $0.16 per 
mile for a positive benefit/cost ratio for the software, with all other costs being equal (see below). 

$28,550 / 15,568 hours = $1.83 per hour (3.31%) 

$28,550 / 178,627 miles = $0.16 per mile (3.33%) 

A second way to conduct this analysis is to include the $28,550 annualized software cost into the 
total annual operating costs, and then determine the number of hours or miles that would need to 
be reduced to reach the break-even point. MET Transit's costs for its demand responsive service 
were $859,612 in 2005. If the $28,550 annual cost for the RouteMatch Software was added to 
the 2005 costs, a total of $888,162 is used as a balance for calculating necessary savings. The 
following calculations yield the needed savings to achieve a break-even point: 

$888,162 / 15,568 hours = $57.05 per hour 

$28,550 / $57.05 per hour = 500 hours (reduction to reach the break-even point) 

$888,162 / 178,627 miles = $4.97 per mile 

$28,550 / $4.97 per mile = 5,744 miles (reduction to reach the break-even point) 



The savings necessary in hours or miles to achieve a break-even point equate to a three percent 
reduction [500 hours / 15,568 hours = 3.2%; 5,744 miles / 178,627 miles = 3.2%] 

As noted earlier in this document, transportation systems implementing computer-aided 
scheduling and dispatching systems have seen a significant increase in efficiency. While Billings 
MET Special Transit has been relatively efficient in that it has several contracts that allows the 
service to group rides, the data in Table 1, Table 2 and Table 3 indicate that MST was more 
efficient during the period analyzed when the RouteMatch software was being used. Because not 
enough cost factors such as fuel and insurance were tracked, it was not possible to determine the 
specific benefit/cost ratio. 
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As indicated in this analysis, however, only a relatively minor gain in efficiency is necessary to 
reach a break-even point for the software. A three percent reduction in mileage or revenue hours 
is all that is required for the software to "pay for itself." 

In addition to the RouteMatch Software, Billings MET Transit also spent approximately $43,500 
to add Automatic Vehicle Location (AVL) technology to its vehicles. This technology is a "stand 
alone" system, in that it was not required as part of the purchase and installation of the 
RouteMatch software. If the cost of the AVL system is amortized over a five-year period, and a 
analysis similar to the software costs is conducted, Billings MET Transit would need to reduce 
its mileage and/or revenue hours by approximately 0.9 percent (142 hours; 1,626 miles) for the 
AVL system to reach the break-even point. 

Finally, the break-even analysis did not take into account additional benefits that may be 
achieved by using the RouteMatch software, such as a reduction in the amount of time it takes to 
compile reports about the transportation systems performance, or invoicing. A time study of the 
dispatchers/schedulers and paratransit managers would have been necessary to capture this data. 
Due to the time and budget of this project, the time study was not possible. Anecdotal evidence 
of an improvement in some of the areas can be captured through the surveys, however, which are 
noted later in this document. 

Time Performance 

There are two times that concern a rider, when they are picked up and when they are dropped off. 
Some riders are more concerned with when they are picked up, while others focus on when they 
are dropped off. The transit agency tries to make sure that they pick up their clients as close to 
the scheduled time as possible, and drop the clients off in as timely a manner as possible. 

In analyzing the time performance, it is also important to remember that while the dispatcher, 
utilizing the software, may create an efficient (timely) manifest, the drivers may chose to alter 
the manifest, or pick up and/or drop off clients in a different order than is indicated by the 
manifest. Further, weather and traffic conditions may warrant changing the order of the rides on 
the manifest. Therefore, while a change in scheduling and dispatching software can have a 
significant impact on the timeliness of a transit system, other factors, such as the drivers' 
adherence to the manifest is also important to consider. 

For this analysis, the data was reviewed and "outliers" were removed. Outliers are typically a 
function of how the software and/or the dispatchers/schedulers deal with "will call" rides. Will 
call rides are rides that do not have a specific time, typically a pick up time, associated with 
them. For instance, a rider may be dropped off at a doctors' appointment, and then will call the 
transit agency when the appointment is done for a pick up. One agency may "guess" that the 
appointment will last an hour or hour and a half, and schedule the return ride based on that 
information, another agency may schedule the return ride for a 5:00 pm pick up and then revise 
that time once the rider calls. 

Based on how will call rides are scheduled, the pick up and drop off time performance of a 
transit system may be skewed. That is why the data was reviewed and "cleaned" before the 
analysis was conducted. This is also why the number of pick up and drop off times are not 
exactly related to the total number of rides that are used in this document. In 2005, we analyzed 
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12,036 pick up and 11,842 drop off times, but noted 17,007 rides. In 2006, 13,647 pick up and 
13,173 drop off times were analyzed and 16,097 rides noted. 

From these figures it can bee seen that cleaning the data leads to an unequal number of pick up 
and drop off times and rides (one pick up and one drop off would equal one ride). The ridership 
is also higher than the number of pick up and drop off times based on how attendants are 
scheduled. If a ride is schedule for a client (one pick up and drop off time), but the client has an 
attendant, then two rides are provided for one pick up and drop off time. Therefore, the number 
of rides in this analysis is higher than the pick up and drop off times because of two factors, the 
"cleaning" of the data and the attendant rides. Additional information on the data can be found in 
Appendix D. 

Pick up Time Performance 

While transportation providers make every effort to arrive as close to the scheduled pick up time 
as possible, the Federal Transit Administration and Americans with Disabilities Act provides for 
a thirty (30) minute "window" for the pick up time for paratransit passengers. Transit providers 
can set this window. Billings MET Special Transit (MST) uses a window of ten (10) minutes 
prior to, and twenty (20) minutes after the scheduled pick up time. For example, if a rider 
schedules a ride with a pick up time of 9:30 am, the vehicle may arrive (and the passenger needs 
to be ready) anytime from 9:20 am to 9:50 am. Further, an early pick up is desirable to 
passengers, as long as the vehicle does not arrive too early [5]. 

In order to evaluate the effectiveness of the RouteMatch software, the pick up times are 
evaluated using the "window" established by MST. Figure D-1 and Figure show the distribution 
of pick up times for the July-September periods for 2005 and 2006 that were analyzed for this 
report. 
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Figure D-1: Distribution of pick up time deviations for 2005 




Figure D-2: Distribution of pick up time deviation for 2006 
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The pick up times were analyzed further, and that data is shown in Table D-4, Table D-5, and 
Table. 



Table D-4: Comparison of pick up 


times 






2005 


2006 


Pick up Time 


count 


percent 


count 


percent 


More than 15 minutes early 


700 


5.80% 


837 


6.13% 


11-15 minutes early 


634 


5.26% 


874 


6.40% 


6-10 minutes early 


1,163 


9.64% 


1,565 


11.47% 


0-5 minutes early 


1,841 


15.26% 


2,342 


17.16% 


On time 


3,685 


30.55% 


1,775 


13.01% 


0-5 minutes late 


1,668 


13.83% 


2,321 


17.01% 


6-10 minutes late 


1,237 


10.25% 


2,018 


14.79% 


11-15 minutes late 


664 


5.50% 


1,050 


7.69% 


16-20 minutes late 


295 


2.45% 


512 


3.75% 


more than 20 minutes late 


176 


1.46% 


353 


2.59% 


Totals 


12,063 


100.00% 


13,647 


100.00% 



Table D-5: Summary statistics for early pick up times 



Statistical Measures 


2005 (Min) 


2006 (Min) 


Number of Observations (N) 


8,023 


7,393 


Sample Mean ( x ) 


4.9811 


6.7047 


Sample Median ( x ) 


2.0 


5.0 


Standard Deviation ( s ) 


6.5662 


6.8584 


Inter Quartile Range (IQR) 


8.0 


9.0 



Table D-6: Summary statist 


tics for late pick up times 


Statistical Measures 


2005 (Min) 


2006 (Min) 


Number of Observations (N) 


7,725 


8,029 


Sample Mean ( x ) 


-4.5377 


-6.8789 


Sample Median ( x ) 


-1.0 


-5.0 


Standard Deviation ( s ) 


6.1565 


6.59 


Inter Quartile Range (IQR) 


8.0 


9.0 



This data shows that in 2005, 87.5 percent of the pick ups were made within the "window" 
established by MET (10 minutes prior, and up to 20 minutes after the scheduled time). In 2006, 
84.9 percent of pick up times were made within the window. Slightly more rides in 2006 were 
more than 10 minutes early compared to 2005, 12.5 percent versus 11.1 percent, but more pick 
ups in 2006 were also more than 20 minutes late, 2.6 percent, versus 1.5 percent in 2005. 
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This is further reflected in Table D-5 and Table, as we see the mean time for an early pick up 
increasing almost two minutes between 2005 and 2006 (5 minutes versus 6.7 minutes early), 
with a similar increase in late pick up times (4.5 minutes late versus 6.9 minutes late). The 
standard deviation for the pick up times also increased between 2005 and 2006, so the software 
may be causing more of a normal distribution in pick up times than was realized with the 
Mobility Master software, when rides were manually scheduled. 

Drop off Time Performance 

As noted earlier, passengers sometimes focus on the pick up time and/or the drop off time. This 
section focuses on the drop off time performance of MET Special Transit, before and after the 
use of RouteMatch software. Unlike pick up times which have a "window" for use, drop off 
times are more dynamic. 

For example, a customer may be picked-up five minutes early, and expect that they would be 
dropped-off five minutes early. However, they may end up being dropped-off ten minutes late. 
Also, customers may have an expectation that the transit service will take close to the same 
amount of time for a trip as would be expected in a car. Those who frequently ride a transit 
system, be it fixed route or demand-responsive, usually realize that it typically takes longer to 
cover the same distance (take a trip) on a transit system versus a car. With this being said, 
however, it is still important to analyze the changes in drop off time performance based on the 
change in software. 

Figure D-3 and Figure D-4 show the distribution of drop off times before (2005) and after (2006) 
the implementation of the RouteMatch Software. Table D-7, Table 8 and Table D-9 show the 
drop off data and analysis. 
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Figure D-3: Distribution of drop off time deviations for 2005 
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Figure D-4: Distribution of drop off time deviations for 2006 



Western Transportation Institute 



97 



Automated Cost Recovery: A Feasibility Study 



Appendix D 



Table D-7: Comparison of drop off times 





2005 


2006 


Drop off Time 


count 


percent 


count 


percent 


More than 15 minutes early 


1,783 


15.06% 


727 


5.52% 


11-15 minutes early 


1,422 


12.01% 


895 


6.79% 


6-10 minutes early 


1,565 


13.22% 


1,396 


10.60% 


.1-5 minutes early 


1,584 


13.38% 


2,194 


16.66% 


On time 


1,896 


16.01% 


1,151 


8.74% 


.1-5 minutes late 


1,409 


11.90% 


2,220 


16.85% 


6-10 minutes late 


936 


7.90% 


1,825 


13.85% 


11-15 minutes late 


638 


5.39% 


1,449 


11.00% 


more than 15 minutes late 


609 


5.14% 


1,316 


9.99% 


Totals 


11,842 


100.00% 


13,173 


100.00% 



Table D-8: Summary statistics for early drop off data for Billings MET Transit 



Statistical Measures 


2005 (Min) 


2006 (Min) 


Number of Observations (N) 


8,250 


6,363 


Sample Mean ( x ) 


9.1555 


7.0773 


Sample Median ( x ) 


8.0 


5.000 


Standard Deviation ( s ) 


7.8206 


6.6799 


Inter Quartile Range (IQR) 


14.0 


9.0 



Table D- 9: Summary statistics for late drop off time for MET Tra nsit data 



Statistical Measures 


2005 (Min) 


2006 (Min) 


Number of Observations (N) 


5,488 


7,961 


Sample Mean ( x ) 


-6.4133 


-8.6376 


Sample Median ( x ) 


-5.0 


-7.0 


Standard Deviation ( s ) 


7.1957 


7.3709 


Inter Quartile Range (IQR) 


10.0 


12.0 



The data indicates that 79.8 percent of the drop offs in 2005 were on-time, or within 15 minutes 
on either side (early or late) of the scheduled drop off time. In 2006, this figure rose to 84.5 
percent of drop off times. However, there was an increase in the percentage of drop offs between 
2005 and 2006 that were more than 15 minutes late, 5 percent versus 10 percent. 
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The variance in early and late drop offs is also reflected in the data shown in Table 8 and Table 
D-9. The average early drop off time decreased almost two minutes between 2005 and 2006, 9.2 
versus 7 minutes), and the standard deviation also decreased, by approximately 1.1 minutes. Late 
drop offs increased, however, as the time increased 2.2 minutes from 2005 to 2006 (6.4 versus 
8.6 minutes), and the standard deviation increased, although very little (7.2 versus 7.4 minutes). 

It is important to remember that the drop off time is typically a function of the software. Prior to 
implementation of RouteMatch, the dispatchers were manually scheduling rides, and may have 
allowed more time between origins and destinations. Therefore, more drop offs could have been 
early, or at least not as late, as when the RouteMatch software was scheduling the rides. While 
analyzing the pick up and drop off times is valuable, it is also valuable to determine the views of 
the people who are using the software, scheduling and dispatching the rides, and operating the 
vehicles. The following section reviews the surveys distributed to MST's drivers and dispatchers. 
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Dispatcher and Driver Surveys 

Two sets of surveys were distributed to both the dispatchers and drivers of MET Special Transit 
(MST). One set was distributed in December 2005 while the Mobility Master software was in 
use, and the second set of surveys was distributed while the RouteMatch software was in use 
(September 2006 for the drivers and April 2007 for the dispatchers). The survey instruments are 
shown in Appendix B. The questions for the two surveys (based on the software) were similar, so 
comparisons could be made. The comments of the dispatchers and drivers are summarized in this 
section, while the full comments can be found in Appendix C. 

The survey administered to the dispatchers was used to determine their opinion on how much the 
software aided them with their duties. The first question of the survey used a seven-point scale 
(7=strongly agree, l=strongly disagree) so the dispatchers could indicate how strongly they 
agreed the software aided them in various tasks they perform. MST has a total of three 
dispatchers, so therefore the responses of one dispatcher can have a significant influence on the 
mean score. It is also important to note that when the initial survey for the RouteMatch software 
was distributed in September 2006, one of the dispatchers was on maternity leave, and no 
surveys were returned. That is why a second attempt was made in April 2007 to have the 
dispatchers complete the survey, which they did. It is not known whether or not having the 
survey conducted at a later time had any influence on the results. The dispatchers' responses to 
the first question of the survey are shown in Table D-10. 



Table D-10: Dispatchers' Responses to Survey Question 1 



Question/Factor 


Mobility Master 
Mean Score 


RouteMatch 
Mean Score 


a) The software helps me schedule individual rides 


1.33 


5.67 


b) The software helps me schedule group rides 


1.33 


3.00 


c) The software helps me schedule subscription (recurring) 
rides 


1.33 


4.00 


d) The software helps me provide a manifest for the drivers 


6.33 


7.00 


e) The manifest (routing) produced by the software is 
efficient 


2.33 


6.33 


f) The manifest produced by the software is accurate in the 
time it takes to get from one stop to another 


3.33 


2.67 


g) The drivers follow the manifest produced by the software 


5.67 


6.67 


h) It is easy to make changes to the manifest 


6.00 


6.33 


i) The software is helpful in generating reports 


4.67 


6.00 


j) Overall the software help me perform my job 


5.33 


6.00 



In general, these results indicate that the dispatchers believe that the RouteMatch software is 
better at assisting them with their various tasks. This may be based on the fact that Mobility 
Master software was not performing any scheduling tasks, and the dispatchers had to schedule all 
of the rides manually. More detailed information about the specifics of the software was obtained 
from the remaining questions of the dispatcher survey, questions 2-4. These questions were 
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open-ended questions that were used to try and get more detailed information about the 
dispatchers' view of the software. 

Question 2 asked, "If there was one thing you could change about the (Mobility Master or 
RouteMatch) software, what would it be?" Question 3 asked the dispatchers to "Please provide 
any comments you have about how the (Mobility Master or RouteMatch) software may or may 
not assist you with your dispatching/scheduling duties." Finally, Question 4 asked the 
dispatchers to "Please provide any other comments you have about technologies, policies or 
procedures that could assist you with your dispatching/scheduling duties." The complete 
comments from the dispatcher and driver surveys can be found in Appendix C. 

Driver Surveys 

The drivers' surveys (one for each of the software) asked a total of four questions. Question 1 
used a seven-point scale (7=strongly agree, l=strongly disagree), so that the drivers could 
indicate their response to seven items related to the software. A total of five drivers completed 
the survey for each software. The drivers' responses are shown in Table D-1 1. 



Table D-11: Drivers' Responses to 


Survey Question ] 




Item 


Mean Score 
Mobility Master 


Mean Score 
RouteMatch 


a) The manifest I get from the dispatchers is accurate 


6.0 


4.2 


b) The manifest I get from the dispatchers is efficient 
(provides a good routing) 


5.6 


4.0 


c) The manifest is accurate in the time it takes to get 
from one stop to another 


4.0 


3.6 


d) I follow the manifest as it is printed 


5.2 


4.8 


e) In order to be more efficient, I don't always 
follow the pick up/drop off order of the manifest 


6.6 


6.4 


f) I believe that I could create a better manifest 
(routing) that is provided by the current software 


3.2 


4.6 


g) Overall, the manifest created by the software 
helps me perform my job 


6.2 


4.8 



In general, the results of the drivers survey tends to indicate that the drivers preferred the 
manifests received from the Mobility Master software. The only item for which RouteMatch 
scored better than Mobility Master was the item relating to whether or not the driver believed 
that they could create a better manifest (item f). 

The remaining questions of the survey (Questions 2-4), were open-ended questions that were 
used to obtain more information from the drivers. Question 2 asked, "If there was one thing you 
could change about the manifests you receive from the dispatchers/schedulers, what would it 
be?" Question 3 asked the drivers to "Please provide any comments you have about how the 
software may or may not assist you with your driving duties." Finally, Question 4 asked the 
drivers to "Please provide any other comments you have about technologies, policies or 
procedures that could assist you with your driving duties." The responses to these questions for 
both the Mobility Master and RouteMatch software are shown in Appendix C. 
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As previously noted, the dispatchers did not use the RouteMatch Scheduling Engine (RSE) 
within the RouteMatch software. Therefore, while the manifests that were produced by the 
dispatchers did look different to the drivers, the dispatchers were still manually scheduling most 
of the rides with the RouteMatch software, as they had with the Mobility Master software. 
Possibly, this was due in part to the fact that many of the rides provided by MET Special Transit 
(MST) are based on contracts, and many of the riders are already grouped by pick up and drop 
off locations. 

It is unclear from this analysis which factors contributed to the changes in the scores in the 
drivers' survey. One hypothesis could be that the drivers were simply not used to the change in 
the appearance of the manifests. It is possible that a second driver survey, a year after the 
RouteMatch software has been in use, may yield different results. 
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CONCLUSIONS 

Previous studies have shown how the use of computer-aided scheduling and dispatching systems 
can increase efficiency in demand-response (or paratransit) organizations [2,4]. The purpose of 
this research was to identify the effects, if any, that implementing RouteMatch software would 
have on the operations of Billings MET Special Transit (MST). MST had been using Mobility 
Master software in its operations, but the dispatchers were manually scheduling rides due to 
issues with the software. MET Special Transit was relatively efficient, mainly due to the fact that 
it has numerous contracts for services, and is skilled at grouping rides. 

The introduction of the RouteMatch software allowed the possibility of the software scheduling 
the rides, to hopefully increase the efficiency of the demand-responsive transit system. The 
Western Transportation Institute (WTI) examined two three-month periods, before and after the 
implementation of the RouteMatch software, to determine the impacts, if any, the software had 
on MST's operations. 

"Before" and "after" data was collected and compared. The data collected for analysis included: 

• Rides per hour, 

• Rides per mile, 

• Dispatcher and driver attitudes, 

• Pick up time performance, and 

• Drop off time performance. 

It was planned that a cost-benefit analysis would occur; however, not enough cost parameters 
such as fuel and insurance prices were collected so that this analysis could be conducted. A 
break-even analysis was conducted, however, which provided information as to how much 
money would need to be saved, in terms of reduced mileage or hours in service, for the 
RouteMatch software to pay for itself. 

The results of the analysis indicate that MST was more efficient when the RouteMatch software 
was being used. This is evident by the rides per hour increasing between the three-month 
comparison period (2005 versus 2006) at 7.04 percent, and the rides per mile increasing by 3.23 
percent. It is this gain in efficiency that allows for the software to save money and achieve a 
break-even point, or "pay for itself." 

Due to the fact that not enough information on cost factors such as average fuel prices, insurance 
costs, etc. were collected for analysis, a direct benefit/cost analysis could not be conducted. The 
break-even analysis that was conducted, however, indicated that only a relatively minor (three 
percent) gain in efficiency would be necessary to reach the break-even point. For example, MET 
Special Transit would only need to provide the same number of rides, while reducing mileage (or 
hours) by three percent. As indicated herein, and by other research, this is certainly an attainable 
goal. 

In addition to the quantifiable information that was analyzed, qualitative data, in the form of 
dispatcher and driver surveys was collected. The dispatchers' responses indicated that they 
believed the RouteMatch software helped them accomplish their various tasks better than the 
Mobility Master software they were previously using. 
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The drivers' surveys indicate that the drivers preferred, for the most part, the manifests (routing) 
provided by the Mobility Master software. In one seemingly contradictory response, however, 
the drivers indicated that the RouteMatch software was superior in producing the manifest 
(routing). One hypothesis for the responses is that the survey was conducted only six months 
after the RouteMatch software was in use, and the drivers may not have adjusted to the new 
manifests. A follow-up survey a year or so after RouteMatch has been in use may yield different 
results. 

The final quantitative data that was analyzed was the pick up and drop off time performance of 
MET Special Transit before and after the implementation of the RouteMatch software. The data 
indicated that fewer pick ups times fell within the 30-minute window established by MST when 
the RouteMatch software was being used (84.9% versus 87.5%). The data also indicated that in 
2006, more pick up times were earlier than the 10-minute window parameter (12.5% versus 
11.1%), but pick up times that were more than 20 minutes late, or fell outside the window, also 
increased when RouteMatch was in use (2.6% versus 1.5%). The drop off time performance 
analysis indicated slightly different results. 

Drop off times do not have a similar window as pick up times, but for this analysis we 
constructed a "window" that was plus or minus fifteen minutes of the scheduled drop off time. In 
2006, when RouteMatch software was in use, more drop off times fell within the 30-minute 
window (84.5% versus 79.8%). Fewer drop off times in 2006, when RouteMatch software was in 
use, were earlier than in 2005 (5.52% versus 15.06%); however, more drop off times were late 
when RouteMatch software was being used (9.99% versus 5.14%). There are several hypotheses 
for the differences in the timing data. 

The first hypothesis is that when RouteMatch was not being used (in 2005), the dispatchers that 
were creating the manifests allowed extra time between origins and destinations, so that more 
pick up and drop off times were within the windows, or were early. This is somewhat related to 
the second hypothesis, which is that when the RouteMatch software was in use, the software 
tried to create a "normal distribution" within the window, which resulted in the results indicated 
herein. 

In summary, based on the data from other research, as well as the data contained herein, the 
implementation of computer-aided scheduling and dispatching software can increase the 
efficiency of demand-responsive (paratransit) organizations. Further, as indicated by the data 
herein specific to MET Special Transit, a gain in efficiency of only three percent, will lead to the 
break-even point to where the software will begin to pay for itself. This relatively short-term 
analysis concluded that MET Special Transit was more efficient with the Route Match software, 
and that the efficiencies necessary to reach the break-even point are achievable. 
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APPENDIX - DATA FOR ANALYSIS 



The following is the data that was utilized for comparison purposes. The data was obtained from 
Billings MET Transit, with further data obtained from the National Transit Database. 



Billings MST Data 





Jul 05 


Jul 06 


Aug 05 


Aug 06 


Sep 05 


Sep 06 


7/05-9/05 


7/06-9/06 


Rides 


5,439 


4,988 


6,034 


5,941 


5,534 


5,168 


17,007 


16,097 


Hours 


1,527 


1,348 


1,701 


1,542 


1,562 


1,351 


4,790 


4,241 


Miles 


17,611 


15,721 


19,370 


18,488 


17,761 


16,357 


54,742 


50,566 




















Rides/Hour 


3.56 


3.70 


3.55 


3.85 


3.54 


3.83 


3.55 


3.80 


Rides/Mile 


0.31 


0.32 


0.31 


0.32 


0.31 


0.32 


0.31 


0.32 



Rides = Ambulatory and Wheel Chair Rides 
Hours = Revenue Hours (Vehicle Hours) 
Miles = Vehicle Miles (Service Miles) 



Billings MET Transit (Demand Responsive) Data - 2005 Totals 



Operating Expenses: $859,612 



Vehicle Revenue Miles: 178,627 



Vehicle Revenue Hours: 15,568 
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APPENDIX - DISPATCHER AND DRIVER SURVEYS 



Surveys were distributed to both the dispatchers and drivers based on both software, Mobility 
Master and RouteMatch. Only the RouteMatch versions of the surveys are included herein. 
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Billings Dispatcher Survey 
RouteMatch Software 



This survey is being conducted by the Western Transportation Institute-Montana State University/ 
Bozeman to help determine the benefits of Scheduling/Dispatching Software. 



To what level do you agree or disagree with the following statements about the RouteMatch 
Software? 



Strongly 












Strongly 


Agree 






Neutral 






Disagree 


7 


6 


5 


4 


3 


2 


1 



a) The software helps me schedule 
individual rides. 

b) The software helps me schedule 
group rides. 

c) The software helps me schedule 
subscription (recurring) rides. 

d) The software helps provide a 
manifest for the drivers. 

e) The manifest (routing) produced by 
the software is efficient. 

f) The manifest produced by the 
software is accurate in the time it takes 
to get from one stop to another. 

g) The drivers follow the manifest 
produced by the software. 

h) It is easy to make changes to the 

manifest. 

i) The software is helpful in generating 

reports. 

j) Overall, the software helps me 

perform my job. 



If there was one thing you could change about the RouteMatch software, what would it be? 



Over^ 
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Please provide any comments you have about how the RouteMatch software may or may not 
assist you with your dispatching/scheduling duties. 



Please provide any other comments you have about technologies, policies or procedures that 
could assist you with your dispatching/scheduling duties. 



Thank you for your time! 
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Strongly 


Neutral 






Disagree 


4 


3 


2 


1 
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g-\ Billings MST Driver Survey ^ 

RouteMatch Software 

This survey is being conducted by tine Western Transportation Institute-Montana State 
University/ Bozeman to Inelp determine tine benefits of Sclneduling/Dispatching Software. 



1 . To what level do you agree or disagree with the following statements about the manifests 
you receive from the dispatchers/schedulers (using RouteMatch Software)? 

Strongly 
Agree 
7 6 5 

a) The manifest I get from the 
dispatchers is accurate. 

b) The manifest I get from the 
dispatchers is efficient (provides a 
good routing). 

c) The manifest is accurate in the 
time it takes to get from one stop 
to another. 

d) I follow the manifest as it is 
printed. 

e) In order to be more efficient, I 
don't always follow the pick- 
up/drop-off order of the manifest. 

f) I believe that I could create a 
better manifest (routing) than is 
provided by the current software. 

g) Overall, the manifest created by 
the software helps me perform my 
job. 

If there was one thing you could change about the manifests you receive from the 
dispatchers/schedulers, what would it be? 



Over^ 
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Please provide any comments you have about how the RouteMatch software may or may not 
assist you with your driving duties. 



Please provide any other comments you have about technologies, policies or procedures that 
could assist you with your driving duties. 



Thank you for your time! 
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APPENDIX - SURVEY COMMENTS 

Dispatcher Comments - Mobility Master 

Notes: The number next to comment is survey number for tracking purposes. Edits were not 
made to the comments. 



Q2. If there was one thing you could change about the Mobility Master software, what would it 
be? 



1) Common locations should be viewed in alphabetical order. 

2) Speed 

3) MM is basically a data entry program w/ no ability to assist in scheduling. 



Q3. Please provide any comments you have about how the Mobility Master software may or may 
not assist you with your dispatching/scheduling duties. 



1) The dispatchers report is on too may sheets of paper. I would like to be able to view more 
quickly for dispatching purposes. Same for the "TBS" sheet. 



Q4. Please provide any other comments you have about technologies, policies or procedures that 
could assist you with your dispatching/scheduling duties. 



2) Speed-accuracy. 

Dispatcher Comments - RouteMatch 

Q2. If there was one thing you could change about the RouteMatch software, what would it be? 



1) When I put in times for pick up or drop off in trips the program doesn't leave them there. I 
have to go into scheduling and change the times. Example: Time to p/u is 9AM, I schedule the 
trip and it pops up in a different time. It's frustrating. 



2) That you can uncancel trips. Ability to cancel all trips according to destination. Holiday 
cancellations by the day. On time reporting. Would like to see better reports on ridership, 
denials, ridership - I get different figures from billing & NTD Report customized for us 



3) I would like to be able to copy & paste times in verification. 

Western Transportation Institute 112 



Automated Cost Recovery: A Feasibility Study Appendix D 



Q3. Please provide any comments you have about how the RouteMatch software may or may not 
assist you with your dispatching/scheduling duties. 



2) The scheduling engine to schedule group rides need some adjusting - I have this issue 
reported to the help desk. The recommendation tool to schedule one ride at a time will give us 
similar trips but not always a feasible schedule 



3) Often times the software chooses ridiculous choices when it comes to scheduling. However, 
overall, the software is better than the software we have used in the past. 



Q4. Please provide any other comments you have about technologies, policies or procedures that 
could assist you with your dispatching/scheduling duties. 



1) There are times when going from one screen to another clicques (editor note: could mean 
"clicks") occur on the new screen. Does timing have to do with this? 



Driver - Mobility Master Survey Comments 

Q2. If there was one thing you could change about the manifests you receive from the 
dispatchers/schedulers, what would it be? 



1) It's OK. 

3) It's fine as-is. 

5) Listing of more accurate times. E.g. p/u 1:00 d/o xtown 1:05 



Q3. Please provide any comments you have about how the Mobility Master software may or may 
not assist you with your driving duties. 



3) The manifest works very well for me, and it is easy to read and follow. 



Q4. Please provide any other comments you have about technologies, policies or procedures that 
could assist you with your driving duties. 



(No comments received) 
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Driver - RouteMatch Survey Comments 

Q2. If there was one thing you could change about the RouteMatch software, what would it be? 

2) The time they give you to go from point A to point B. They will give you 5 min. to drive 6 
miles and 15 min. to drive 2 miles. 

4) Sometimes, there is no business name with the addresses or apartment #s, but for the most 
part, the people are the same, so you remember where to go I guess. 

5) Times given-inaccurate 



Q3. Please provide any comments you have about how the RouteMatch software may or may not 
assist you with your driving duties. 



2) The times on the manifest did not change at all when they got the new software-not even close 
to reality. Sometimes they have wrong addresses on manifests or not enough information at all- 
telling management about this things doesn't do any good-nothing changes. 



3) Doesn't always allow proper times between stops. 

4) Its OK for the most part. 

5) Keeps me on my toes-confuses me daily. 



Q4. Please provide any other comments you have about technologies, policies or procedures that 
could assist you with your driving duties. 



2) Some of these parking lots and driveways ware are sent to are next to impossible to get around 
in and if we do any damage it is our butt on the line-management and dispatchers don't have a 
clue what we go through, they don't seem to tell everybody (clients) about the 10 min. policy 
and then people get mad at us for doing our job, manifests are pretty much of a joke; we strap 
people in, but have no control over people if they loosen or undo their seatbelts, we have to drive 
in crazy traffic and can't watch clients every minute and if something happens, we get written up 
for it. 



3) Take into consideration traffic in certain areas of town. 
5) There has to be a better way. 
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APPENDIX - DETAILED TIME ANALYSIS 



There were two sets of data collected to conduct this analysis. The first set of data contains the 
information about all the rides provided by Billings MET Special Transit for the months of July, 
August and September for the year 2005. The data has 12,202 observations, documenting pick 
up and drop off times of every ride provided during the time period. We initially conducted a dot 
plot to analyze the integrity of the data. The pick up times and drop off times were plotted 
separately. 

Unprocessed Data Analysis 

Figure D-5 shows the pick up time dot plot. It is evident from the dot plot that there are large 
outlying values. These values occur due to the way the "Will Call" rides are setup. Will call rides 
are used by dispatchers for rides such as after a doctor's appointment, when the rider will call 
and say they are ready to be picked-up. Thus after examining the dot plots and the frequency 
table for the data, we decided to reject data values with pick up deviations that are earlier than or 
later than 30 minutes as outliers. 
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Figure D-5: Dot plot showing unprocessed data for pick up time deviations 
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Figure D-6: Dot plot showing unprocessed data for drop off time deviations 



Figure D-6 shows that a similar pattern is noticeable in drop off times as well. The same practice 
of marking "Will Calls" at the end of the day results in the outliers. After combined examination 
with the frequency distribution and the dot plots we decided to discard drop off time deviations 
earlier of later than 45 minutes as outliers. 

The initial analyses on the unprocessed data provided us with the information necessary to filter 
and clean the data. Only the filtered data was used for our analysis. Table D-1 summarizes the 
raw and clean data. 



Table D-12: Summary information on pick up and drop off data after filtering 



Year 


Data Characteristic 


Total Obs 


Valid Obs 


Usable % 


Outlier % 


2005 


Pick up times 


12,202 


12,063 


98.86 


1.14 


Drop off times 


12,202 


11,842 


97.05 


2.95 


2006 


Pick up times 


13,965 


13,647 


97.72 


2.28 


Drop off times 


13,965 


13,173 


94.33 


5.67 



The data was then split into four groups, which were: 

1 . Early passenger pick up 

2. Late passenger pick up 

3. Early passenger drop off 

4. Late passenger drop off 
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Processed Data Analysis 

Much of the data was presented in the main section of this document. However, additional 
analysis is included herein for those interested in further details. To show the spread and 
characteristics of the data we created a box plot for pick up and drop off times. We utilized the 
labels shown in Table D-1 for the box plots. Figure D-7 shows the box plot for early pick up 
times for 2005, while Figure D-8 shows the box plot for year 2006. It can be seen that all the 
three quartiles with median is visible for all time categories for year 2006, and shows almost 
uniform variation, supporting the fact that the software has reduced variability in pick up times 
by grouping rides. 



Table D-13: Time Measures of Effectiveness 



Description 


Comments 


More than 15 minutes early 


Unacceptable (UA) 


10.1-15 minutes early 


Satisfactory (S) 


5.1-10 minutes early 


Acceptable (A) 


.1-6 minutes early 


Somewhat Desirable (SD) 


On time pick up (0 minutes early) 


Most Desirable (MD) 


.1-5 minutes late 


Somewhat Desirable (SD) 


5.1-10 minutes late 


Acceptable (A) 


10.1 -20 minutes late 


Satisfactory (S) 


More than 20 minutes late 


Unacceptable (UA) 
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Figure D-7: Box plot of early pick up times categories for 2005 
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Figure D-8: Box plot of early pick up time categories for 2006 



Figure D-9 shows the box plot for early drop off times for 2005, while Figure D-10 shows the 
data for 2006. By comparing both diagrams we can see that in year 2006, the variability within 
the 10 minute window of the scheduled drop off time is minimal. This may be achieved by 
grouping rides to similar locations, which might be the work of the scheduling algorithm, which 
would result in dropping-off passengers closer to their scheduled time, as compared to 2005. 




Figure D-9: Box plot of early drop off time categories for 2005 
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Figure D-10: Box plot of early drop off time categories for 2006 



Figure D-11 represents the box plot showing the categories for the late pick up data for 2005, 
while Figure D-12 shows the same data for 2006. Interestingly, we can see that the 6 -10 minute 
late pick ups and 11-15 minutes late pick up displays similar spread and quartiles, suggesting 
that two subdivisions could be considered together. From Figure D-12 it is worth noticing that 
the variation in the lateness for year 2006 shows a uniform behavior compared to the non- 
uniformity shown in year 2005 in Figure D-11. 
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Figure D-11: Box plot for late pick up categories for 2005 
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Figure D-12: Box plot for late pick up categories for 2006 



Figure D-13 represents the box plot showing the spread of the late drop off data for 2005. It is 
noticeable that the 10 - 15 minute late and greater than 15 minute late categories exhibit the 
same pattern in year 2006 (Figure D-14). This point to the situation where rides that are already 
delayed are further delayed to keep the rides that are on time to be completed within the 
scheduled time. The scheduling algorithm parameter settings need to be known to make a 
complete analysis. 




Figure D-13: Box plot for late drop off categories for 2005 
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Figure D-14: Box plot for late drop off categories for 2006 
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APPENDIX - SAS ANALYSIS PROGRAM FOR TIME-RELATED DATA 



* Program to read the ride data for Billings MET transit system and 
thus 

evaluate the effectiveness of the RouteMatch program; 

* Code written by Deepu Philip; 

* Date: 05/23/2006; 

* Please notice: 

All code is copyrighted by Deepu Philip and subject to the 
GNU General Public License, specif icially, the following 
applies to all files: 

Copyright (C) 2006 Deepu Philip, dphilip@montana.edu 

This program is free software, you can redistribute it and/or 
modify it under the terms of the GNU General Public License 
as published by the Free Software Foundation, either version 2 
of the License, or (at your option) any later version. 

This program is distributed in the hope that it will be useful, 
but WITHOUT ANY WARRANTY, without even the implied warranty of 
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the 
GNU General Public License for more details. 

You should have received a copy of the GNU General Public License 
along with this program in license.txt. 

If you haven't received a copy, write to the Free Software 
Foundation, Inc., 59 Temple Place - Suite 330, Boston, 

MA 02111-1307, USA, or browse to 

http : //www . gnu .org/licenses/gpl. html . ; 

* this section obtains data from the file based on given file type; 
DATA RIDE; * read the accident data from file; 

INFILE 'C:\DEEPU\WTI\2006SUMMER\BILLINGSDATAJULYSEPT2005.CSV' DLM = 

1 1 
f 

FIRSTOBS = 2 LRECL = 500; 
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LENGTH SRV_DATE $ 25; * service date; 

LENGTH PUTM $ 25; * Pickup time; 

LENGTH DOTM $ 25; * Dropoff time; 

LENGTH ACT_PUTM $ 25; * actual Pickup time; 

LENGTH ACT_DOTM $ 25; * actual Dropoff time; 

LENGTH PU_EL $ 6; * Pickup early or late; 

LENGTH DO_EL $ 6; *Dropoff early or late; 

LENGTH TRIP_SC $ 5; * trip status code; 

LENGTH TRIP_SD $ 10; * trip status description; 

LENGTH TRIP_TYP $ 3; * trip type; 

* input all the fields in the data file for program to read; 
INPUT SRV_DATE $ PUTM $ DOTM $ ACT_PUTM $ ACT_DOTM $ PU_DEL PU_EL $ 

DO_DEL DO_EL $ TRIP_SC $ TRIP_SD $ TRIP_TYP $; 

* any non numeric values are removed; 
IF DO_DEL=. THEN DELETE; 

IF PU_DEL=. THEN DELETE; 

OBS_NO +1; * adding an observation number with the data set; 

DROP SRV_DATE; * drop unused variables; 
RUN; 

* check whether the input is correct 

This is again another debug option and will be turned off during runs; 

PROC PRINT DATA = RIDE; 

TITLE 'BILLINGS RIDE DATA YEAR 2005'; 

VAR OBS_NO DOTM PU_DEL DO_DEL TRIP_TYP; * variables to print; 
RUN; 



DATA RIDEMODIF; * modify the ride data; 
SET RIDE; * set old data; 

* now parse the scheduled pickup and drop off times; 
LENGTH PUDATE $ 10; * scheduled pickup date; 



Western Transportation Institute Page 123 



Automated Cost Recovery: A Feasibility Study Appendix E 

LENGTH DODATE $ 10; * scheduled dropoff date; 
LENGTH PUTIME $ 6; * scheduled pickup time; 
LENGTH DOTIME $ 6; * scheduled dropoff time; 

PUDATE = SCAN (PUTM, 1, ' '); * get date information from the string; 
PUTIME = SCAN (PUTM, 2, ' '); * get time information; 
PUTIMEHRS = + SCAN (PUTIME, 1, ':') ; * hour of pickup; 
PUTIMEMIN = SCAN (PUTIME, 2, ':') ; * minute of pickup; 

DODATE = SCAN (DOTM, 1, ' '); * get date information from the string; 
DOTIME = SCAN(DOTM, 2, ' '); * get time information; 
DOTIMEHRS = + SCAN ( DOTIME, 1, ':') ; * hour of dropoff; 
DOTIMEMIN = SCAN (DOTIME, 2, ':') ; * minute of dropoff; 

DROP PUTM DOTM PUTIME DOTIME; * drop parsed variables; 

* now convert the pickup early late to binary variable; 

IF PU_EL EQ 'early' THEN BNPUEL =1; * early is denoted by 1; 
ELSE IF PU_EL EQ 'late' THEN BNPUEL =0; * late is denoted by 0; 
ELSE BNPUEL = 99; * missing values; 

DROP PU_EL; * drop the string; 

* now convert the dropoff early late to binary variable; 

IF DO_EL EQ 'early' THEN BNDOEL =1; * early is denoted by 1; 
ELSE IF DO_EL EQ 'late' THEN BNDOEL =0; * late is denoted by 0; 
ELSE BNDOEL = 99; * missing values if any; 

DROP DO_EL; * drop the string; 

* now parse the actual pickup and drop off times; 

/* this info is redundant as we can obtain the same from the deltas 
LENGTH APUDATE $ 10; * actual pickup date; 
LENGTH ADODATE $ 10; * actual dropoff date; 
LENGTH APUTIME $ 6; * actual pickup time; 
LENGTH ADOTIME $ 6; * actual dropoff time; 



Western Transportation Institute Page 124 



Automated Cost Recovery: A Feasibility Study Appendix E 



string; 



string; 



APUDATE = SCAN(ACT_PUTM, 1, ' ' ) ; * get date information from the 

APUTIME = SCAN(ACT_PUTM, 2, ' '); * get time information; 

ADODATE = SCAN{ACT_DOTM, 1, ' '); * get date information from the 

ADOTIME = SCAN(ACT_DOTM, 2, ' '); * get time information; */ 

DROP ACT_PUTM ACT_DOTM; * drop parsed variables; 



RUN; 



* check whether the data modification is correct 

just for debugging and will only be turned on when needed; 
PROC PRINT DATA = RIDEMODIF; 

TITLE 'BILLINGS RIDE PARSED DATA'; 

VAR PUDATE PUTIMEHRS PUTIMEMIN PU_DEL BNPUEL DOTIME DO_DEL 
TRIP_TYP; * variables to print; 
RUN; 

* now the initial analysis of the data begins. 

The analysis is accomplished by a series of sas procedures 
generate a freguency distribution for pickup deltas; 
PROC FREQ DATA = RIDEMODIF; 

TITLE 'Billings scheduled pickup times - freguency distribution'; 

TABLES PU_DEL; 
RUN; 

* generate a freguency distribution for drop off deltas; 
PROC FREQ DATA = RIDEMODIF; 

TITLE 'Billings scheduled drop off times - freguency distribution'; 
TABLES DO_DEL; 
RUN; 

* we now do the dot plots to visualize the spread of the data; 

* set the graphics environment for doing the dot plots; 
GOPTIONS RESET=all; 

SYMBOL COLOR = PURPLE; 

* generate dot plot for the pickup times; 
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PROC GPLOT DATA = RIDEMODIF; 

PLOT PU_DEL*OBS_NO; 
RUN; 

* generate dot plot for the dropoff times; 
PROC GPLOT DATA = RIDEMODIF; 

PLOT DO_DEL*OBS_NO; 
RUN; 

* from analysis it is clear that there are extreme observations that 
are 

creating a skew in the data. 

The reasons for the outliers are the current way of putting the 
willcalls . 

So we are modifying the data after discarding the outliers. 

Create data sets for pickup and drop off times; 

DATA PICKUP (KEEP = OBS_NO PUDATE PUTIMEHRS PUTIMEMIN PU_DEL) 

DROPOFF (KEEP = OBS_NO DODATE DOTIMEHRS DOTIMEMIN DO_DEL); 
SET RIDEMODIF; * initially analyzed data set; 
RUN; 

* print to see whether the data sets are created correctly 
this is just a debug tool; 

PROC PRINT DATA = PICKUP; 

TITLE 'Billings passenger pickup time data only (2005)'; 

VAR OBS_NO PUDATE PUTIMEHRS PU_DEL; * variables to print; 
RUN; 

* create early pickup data set from the pickup; 
DATA PICKUPE; 

SET PICKUP; 

IF PU_DEL < THEN DELETE; * keep only the positive pickup times; 
IF PU_DEL > 30 THEN DELETE; * remove outliers; 
RUN; 

* create late pickup data set from the pickup; 
DATA PICKUPL; 

SET PICKUP; 
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* include zero in the late pickup according to the coding in data; 
IF PU_DEL > THEN DELETE; * keep only the negative pickup times; 
IF PU_DEL < -30 THEN DELETE; * remove outliers; 
RUN; 

* print to see whether the data sets are created correctly 
this is just a debug tool; 

PROC PRINT DATA = PICKUPL; 

TITLE 'Billings passenger late pickup time data only (2005) '; 

VAR OBS_NO PUDATE PUTIMEHRS PU_DEL; * variables to print; 
RUN; 

* now modify the early pickup data with MOE; 
DATA PICKUPE_MOE; 

SET PICKUPE; 
LENGTH MOE $ 2; 

* now analyze generate variables for earliness; 
IF PU_DEL = THEN MOE = ' MD ' ; 
ELSE IF < PU_DEL <= 5 THEN MOE = ' SD ' ; 
ELSE IF 5 < PU_DEL <= 10 THEN MOE = 'A'; 
ELSE IF 10 < PU_DEL <= 15 THEN MOE = 'S'; 
ELSE IF PU_DEL > 15 THEN MOE = ' UA ' ; 
RUN; 

* print to see whether the data sets are created correctly 
this is just a debug tool; 

PROC PRINT DATA = PICKUPE_MOE; 

TITLE 'Billings passenger early pickup modified data (2005) '; 

VAR OBS_NO PUDATE PUTIMEHRS PU_DEL MOE; * variables to print; 
RUN; 

* now obtain the freguency table for the MOE from the early pickup 
data; 

PROC FREQ DATA = PICKUPE_MOE; 

TITLE 'Freguency Distribution for Early Pickup Data - Billings 
(2005) ' ; 

TABLES MOE; 
RUN; 
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* sort the data to generate a box plot for early pickup times; 
PROC SORT DATA = PICKUPE_MOE OUT = PICKUPE_MOEST ; 

BY PU_DEL; 
RUN; 

* now create the box plot; 

TITLE 'Boxplot for Early Pickup Times Data - Billings (2005)'; 
PROC BOXPLOT DATA = PICKUPE_MOEST; 

PLOT PU_DEL * MCE / BOXSTYLE = SCHEMATICID CBOXES = BLUE BOXWIDTH 
= 10; 

RUN; 

* run the procedure for generating summary statistics for early pickup 
data; 

PROC UNIVARIATE DATA = PICKUPE_MOEST NORMAL PLOT; 

TITLE 'Summary statistics for Early Pickup data - Billings 
(2005) ' ; 

VAR PU_DEL; 
RUN; 

* now modify the late pickup data with MOE; 
DATA PICKUPL_MOE; 

SET PICKUPL; 
LENGTH MOE $ 2; 

* now analyze generate variables for lateness; 
IF PU_DEL = THEN MOE = ' MD ' ; 
ELSE IF > PU_DEL >= -5 THEN MOE = ' SD ' ; 
ELSE IF -5 > PU_DEL >= -10 THEN MOE = 'A'; 
ELSE IF -10 > PU_DEL >= -15 THEN MOE = 'S'; 
ELSE IF PU_DEL < -15 THEN MOE = ' UA ' ; 
RUN; 

* now obtain the frequency table for the MOE from the late pickup data; 
PROC FREQ DATA = PICKUPL_MOE; 

TITLE 'Frequency Distribution for Late Pickup Data - Billings 
(2005) ' ; 

TABLES MOE; 
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RUN; 



* sort the data to generate a box plot for late pickup times; 
PROC SORT DATA = PICKUPL_MOE OUT = PICKUPL_MOEST ; 

BY PU_DEL; 
RUN; 

* now create the box plot; 

TITLE 'Boxplot for Late Pickup Times Data - Billings (2005)'; 
PROC BOXPLOT DATA = PICKUPL_MOEST; 

PLOT PU_DEL * MCE / BOXSTYLE = SCHEMATICID CBOXES = BLUE BOXWIDTH 
= 10; 

RUN; 

* run the procedure for generating summary statistics for late pickup 
data; 

PROC UNIVARIATE DATA = PICKUPL_MOEST NORMAL PLOT; 

TITLE 'Summary statistics for Late Pickup data - Billings 
(2005) ' ; 

VAR PU_DEL; 
RUN; 

* now replicate the analysis for the drop off times 
create the early and late drop off time data; 

* create early pickup data set from the pickup; 
DATA DROPOFFE; 

SET DROPOFF; 

IF DO_DEL < THEN DELETE; * keep only the positive pickup times; 
IF DO_DEL > 30 THEN DELETE; * remove outliers; 
RUN; 

* create late pickup data set from the pickup; 
DATA DROPOFFL; 

SET DROPOFF; 
* include zero in the late pickup according to the coding in data; 
IF DO_DEL > THEN DELETE; * keep only the negative pickup times; 
IF DO_DEL < -30 THEN DELETE; * remove outliers; 
RUN; 
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* print to see whether the data sets are created correctly 
this is just a debug tool; 

PROC PRINT DATA = DROPOFFE; 

TITLE 'Billings passenger early drop off time data only (2005) '; 

VAR OBS_NO DODATE DOTIMEHRS DO_DEL; * variables to print; 
RUN; 

* now modify the early drop off data with MOE; 
DATA DROPOFFE_MOE; 

SET DROPOFFE; 
LENGTH MOE $ 2; 

* now analyze generate variables for earliness; 
IF DO_DEL = THEN MOE = ' MD ' ; 
ELSE IF < DO_DEL <= 5 THEN MOE = 'SD'; 
ELSE IF 5 < DO_DEL <= 10 THEN MOE = 'A'; 
ELSE IF 10 < DO_DEL <= 15 THEN MOE = 'S'; 
ELSE IF DO_DEL > 15 THEN MOE = ' UA ' ; 
RUN; 

* print to see whether the data sets are created correctly 
this is just a debug tool; 

PROC PRINT DATA = DROPOFFE_MOE; 

TITLE 'Billings passenger early drop off modified data with MOE 
(2005) ' ; 

VAR OBS_NO DODATE DOTIMEHRS DO_DEL MOE; * variables to print; 
RUN; 

* now obtain the frequency table for the MOE from the early drop off 
data; 

PROC FREQ DATA = DROPOFFE_MOE; 

TITLE 'Frequency Distribution for Early Drop off Data - Billings 
(2005) ' ; 

TABLES MOE; 
RUN; 

* sort the data to generate a box plot for early drop off times; 
PROC SORT DATA = DROPOFFE_MOE OUT = DROPOFFE_MOEST ; 
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BY DO_DEL; 
RUN; 

* now create the box plot; 

TITLE 'Boxplot for Early Drop off Times Data - Billings (2005)'; 
PROC BOXPLOT DATA = DROPOFFE_MOEST; 

PLOT DO_DEL * MCE / BOXSTYLE = SCHEMATICID CBOXES = BLUE BOXWIDTH 
= 10; 

RUN; 

* run the procedure for generating summary statistics for early drop 
off data; 

PROC UNIVARIATE DATA = DROPOFFE_MOEST NORMAL PLOT; 

TITLE 'Summary statistics for Early Drop off data - Billings 
(2005) ' ; 

VAR DO_DEL; 
RUN; 



* now modify the late drop off data with MOE; 
DATA DROPOFFL_MOE; 

SET DROPOFFL; 
LENGTH MOE $ 2; 

* now analyze generate variables for lateness; 
IF DO_DEL = THEN MOE = ' MD ' ; 
ELSE IF > DO_DEL >= -5 THEN MOE = ' SD ' ; 
ELSE IF -5 > DO_DEL >= -10 THEN MOE = 'A'; 
ELSE IF -10 > DO_DEL >= -15 THEN MOE = 'S'; 
ELSE IF DO_DEL < -15 THEN MOE = ' UA ' ; 
RUN; 

* print to see whether the data sets are created correctly 
this is just a debug tool; 

PROC PRINT DATA = DROPOFFL_MOE; 

TITLE 'Billings passenger late drop off modified data with MOE 
(2005) ' ; 

VAR OBS_NO DODATE DOTIMEHRS DO_DEL MOE; * variables to print; 
RUN; */ 
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* now obtain the frequency table for the MCE from the late drop off 
data; 

PROC FREQ DATA = DROPOFFL_MOE; 

TITLE 'Frequency Distribution for Late Drop off Data - Billinqs 
(2005) ' ; 

TABLES MCE; 
RUN; 

* sort the data to generate a box plot for late drop off times; 
PROC SORT DATA = DROPOFFL_MOE OUT = DROPOFFL_MOEST ; 

BY DO_DEL; 
RUN; 

* now create the box plot; 

TITLE 'Boxplot for Late Drop off Times Data - Billings (2005)'; 
PROC BOXPLOT DATA = DROPOFFL_MOEST; 

PLOT DO_DEL * MCE / BOXSTYLE = SCHEMATICID CBOXES = BLUE BOXWIDTH 
= 10; 

RUN; 

* run the procedure for generating summary statistics for late drop off 
data; 

PROC UNIVARIATE DATA = DROPOFFL_MOEST NORMAL PLOT; 

TITLE 'Summary statistics for Late Drop off data - Billings 
(2005) ' ; 

VAR DO_DEL; 
RUN; 

DATA PICKUPT; 

SET PICKUP; 

IF PU_DEL < -30 THEN DELETE; * outliers; 

IF PU_DEL > 30 THEN DELETE; * outliers; 
RUN; 

* now modify the pickup data data with MOE; 
DATA PICKUPT_MOE; 

SET PICKUPT; 

Western Transportation Institute Page 132 



Automated Cost Recovery: A Feasibility Study Appendix E 

LENGTH MCE $ 2; 

* now analyze generate variables for lateness; 
IF PU_DEL >= -15 THEN MCE = 'A'; 
ELSE IF -15 > PU_DEL >= -10 THEN MCE = 'B'; 
ELSE IF -10 > PU_DEL >= -6 THEN MCE = ' C ' ; 



ELSE 


IF 


PU_DEL 


= 


-5 


THEN 


MCE = 


'D'; 


ELSE 


IF 


PU_DEL 


= 


-4 


THEN 


MOE = 


'E'; 


ELSE 


IF 


PU_DEL 


= 


-3 


THEN 


MCE = 


'F'; 


ELSE 


IF 


PU_DEL 


= 


-2 


THEN 


MOE = 


'G'; 


ELSE 


IF 


PU_DEL 


= 


-1 


THEN 


MOE = 


'H'; 


ELSE 


IF 


PU_DEL 


= 





THEN 


MOE = 


'I'; 


ELSE 


IF 


PU_DEL 


= 


1 


THEN 


MOE = 


'J'; 


ELSE 


IF 


PU_DEL 


= 


2 


THEN 


MOE = 


'K'; 


ELSE 


IF 


PU_DEL 


= 


3 


THEN 


MOE = 


'L'; 


ELSE 


IF 


PU_DEL 


= 


4 


THEN 


MOE = 


'M' ; 


ELSE 


IF 


PU_DEL 


= 


5 


THEN 


MOE = 


'N'; 


ELSE 


IF 


5 < PU_ 


_DEL 


<= 10 


THEN 


yiOE = ' ' ; 


ELSE 


IF 


10 < PU_ 


DEL 


<= 15 THEN 


MOE = 'P' ; 



RUN; 



* now sort the pickup times with MOE for normal plot; 
PROC SORT DATA=PICKUPT_MOE; 

BY MOE; 
RUN; 

* create the normal plot on the whole pickup times; 

* the normal plot procedure code is modifed as a macro; 
TITLE 'NORMAL PLOT FOR WHOLE PICKUP TIMES - Billings (2005)'; 
PROC UNIVARIATE DATA=PICKUPT_MOE; 

HISTOGRAM PU_DEL/ CBARLINE = BLUE NORMAL; 
RUN; 

* drop off analysis begin here - the procedure remains the same; 

* different data sets are used; 

* now do the same analysis for drop off times; 
DATA DROPOFF T; 

SET DROPOFF; 
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IF DO_DEL < -30 THEN DELETE; * outliers; 
IF DO_DEL > 30 THEN DELETE; * outliers; 

RUN; 

* now modify the pickup data data with MOE; 

DATA DROPOFFT_MOE; 
SET DROPOFFT; 
LENGTH MOE $ 2; 

* now analyze generate variables for lateness; 

IF DO_DEL >= -15 THEN MOE = 'A'; 

ELSE IF -15 > DO_DEL >= -10 THEN MOE = 'B'; 

ELSE IF -10 > DO_DEL >= -6 THEN MOE = 'C; 

ELSE IF DO_DEL = -5 THEN MOE = 'D' 

ELSE IF DO_DEL = -4 THEN MOE = 'E' 

ELSE IF DO_DEL = -3 THEN MOE = 'F' 

ELSE IF DO_DEL = -2 THEN MOE = 'G' 

ELSE IF DO_DEL = -1 THEN MOE = 'H' 

ELSE IF DO_DEL = THEN MOE = 'I'; 



ELSE IF DO_DEL 

ELSE IF DO_DEL 

ELSE IF DO_DEL 

ELSE IF DO_DEL 

ELSE IF DO DEL 



1 THEN MOE 

2 THEN MOE 

3 THEN MOE 

4 THEN MOE 

5 THEN MOE 



'J'; 

'K'; 
'L'; 
'M' ; 
'N' ; 



ELSE IF 5 < DO_DEL <= 10 THEN MOE = '0'; 
ELSE IF 10 < DO_DEL <= 15 THEN MOE = 'P'; 
ELSE IF DO_DEL> 15 THEN MOE = 'Q'; 



RUN; 



* sort the drop off times for normal plot; 
PROC SORT DATA=DROPOFFT_MOE; 

BY MOE; 
RUN; 

* now display the normal plot for the drop off times; 

* the modified procedure is used as a macro; 

TITLE 'NORMAL PLOT FOR WHOLE DROPOFF TIMES - Billings (2005)'; 
PROC UNIVARIATE DATA=DROPOFFT_MOE; 

HISTOGRAM DO_DEL/ CBARLINE = BLUE NORMAL; 
RUN; 
QUIT; 
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